Using wget will directly download without specify ak sk

[whybeyoung]

my dockercompose file:

version: "2"
services:
  s3:
    image: hub..com/xxxx/s3proxy:latest
    container_name: s3proxy
    # name: https://github.com/gaul/s3proxy/blob/master/Dockerfile
    environment:
       - S3PROXY_AUTHORIZATION=aws-v2-or-v4
       - S3PROXY_IDENTITY=hellow
       - S3PROXY_CREDENTIAL=1234cccc
       - LOG_LEVEL=debug
       - S3PROXY_CORS_ALLOW_HEADERS=Authorization
    ports:
      - "8080:80"
    volumes:
      - /data1/fs:/data
networks:
  default:
    external:
      name: s3

then use command wget localhost:8080/bucket/file1 will directly download the file ..

is there an permission check bug here?

[gaul]

This seems unlikely given the negative credentials tests in AwsSdkTest.testAwsV4SignatureBadCredential. I'm not sure what code you are running with the image hub..com/xxxx/s3proxy:latest. Perhaps this third-party image disables authentication? Also maybe try experimenting with different values for S3PROXY_AUTHORIZATION and S3PROXY_CORS_ALLOW_HEADERS to see if this influences the behavior. You can also see more detail about what is happening with credentials checking by setting LOG_LEVEL=trace.

[whybeyoung]

thanks for the reply.

hub..com/xxxx/s3proxy:latest is the offical image from the docker hub. it's version is 1.8.1:

version:

using wget：

use programing code:
specify right ak sk:

specify wrong ak sk:

the cotainer env:

version: "2"
services:
  s3:
    image: official/s3proxy:latest
    container_name: s3proxy
    # name: https://github.com/gaul/s3proxy/blob/master/Dockerfile
    environment:
       - S3PROXY_AUTHORIZATION=aws-v2-or-v4
       - S3PROXY_IDENTITY=hellow
       - S3PROXY_CREDENTIAL=1234cccc
       - S3PROXY_ENDPOINT=http://0.0.0.0:8080
       - LOG_LEVEL=trace
       - S3PROXY_CORS_ALLOW_HEADERS=Authorization ETag
       - JCLOUDS_REGION=default
    ports:
      - "8080:8080"
    volumes:
      - /data1/fs:/data
networks:
  default:
    external:
      name: s3

[whybeyoung]

Closed. The file must be uploaded by the s3 inteface rather than existed file (may be lack of some attrs)

@gaul

[gaul]

I can reproduce these symptoms. First with a blob created by the AWS CLI and retrieved via wget:

[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:298 |::] request: Request(GET //127.0.0.1:8081/s3proxy-bucket/foo)@ff565b7
[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Accept: */*
[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: User-Agent: Wget/1.21.1
[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Connection: keep-alive
[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Host: 127.0.0.1:8081
[s3proxy] D 08-16 21:44:06.897 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Accept-Encoding: identity
[s3proxy] D 08-16 21:44:06.898 S3Proxy-Jetty-18 o.gaul.s3proxy.S3ProxyHandler:2919 |::] sendSimpleErrorResponse: 403 AccessDenied Forbidden {}

Next when created via direct filesystem access and retrieved via wget:

[s3proxy] D 08-16 21:44:12.096 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:298 |::] request: Request(GET //127.0.0.1:8081/s3proxy-bucket/bar)@5ddcdf72
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Accept: */*
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: User-Agent: Wget/1.21.1
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Connection: keep-alive
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Host: 127.0.0.1:8081
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.gaul.s3proxy.S3ProxyHandler:323 |::] header: Accept-Encoding: identity
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.j.b.config.LocalBlobStore:56 |::] Retrieving blob with key bar from container s3proxy-bucket
[s3proxy] D 08-16 21:44:12.097 S3Proxy-Jetty-13 o.j.b.config.LocalBlobStore:56 |::] Opening blob in container: s3proxy-bucket - bar

[gaul]

Can you check the permissions on your file? I found that when it had world-readable 0664 then S3Proxy allowed reading it but without 660 it did not allow reading. The reason for this is that S3Proxy converts the S3 public access metadata into the world readable bit.

[whybeyoung]

Can you check the permissions on your file? I found that when it had world-readable 0664 then S3Proxy allowed reading it but without 660 it did not allow reading. The reason for this is that S3Proxy converts the S3 public access metadata into the world readable bit.

checked. and my file has 644, change to 640will be ok