Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using wget will directly download without specify ak sk #363

Closed
whybeyoung opened this issue Aug 11, 2021 · 6 comments
Closed

Using wget will directly download without specify ak sk #363

whybeyoung opened this issue Aug 11, 2021 · 6 comments
Labels

Comments

@whybeyoung
Copy link

whybeyoung commented Aug 11, 2021

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
Copy link
Owner

gaul commented Aug 11, 2021

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.

@gaul gaul added the needinfo label Aug 11, 2021
@whybeyoung
Copy link
Author

thanks for the reply.

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

version:
image

using wget:
image

use programing code:
specify right ak sk:
image

specify wrong ak sk:
image

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
Copy link
Author

whybeyoung commented Aug 16, 2021

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

@gaul

@gaul gaul reopened this Aug 16, 2021
@gaul
Copy link
Owner

gaul commented Aug 16, 2021

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
Copy link
Owner

gaul commented Aug 16, 2021

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.

@gaul gaul closed this as completed Aug 16, 2021
@whybeyoung
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants