Bucket policy doesn't work for `private` buckets

dkirillov commented

2024-02-07 09:12:38 +00:00

Member

We cannot provide access to different user (in the same namespace) using PutBucketPolicy

Expected Behavior

Different user can put object to our bucket

Current Behavior

Got error AccessDenied

In logs:

2024-02-07T12:07:43.516+0300    error   handler/util.go:46      request failed  {"status": 403, "request_id": "53e9c533-ef54-4bed-8d0a-fb930f2ed665", "method": "PutObject", "bucket": "policy-test", "object": "obj", "description": "could not get bucket settings", "error": "couldn't get node: access denied: access denied: rpc error: code = Unknown desc = access to operation GET is denied by extended ACL check: DENY eACL rule"}

Possible Solution

Don't set eacl when create bucket but use APE rules to restrict access.

Steps to Reproduce (for bugs)

Create bucket:

$ aws s3api --endpoint http://localhost:8084  create-bucket --bucket policy-test

Put bucket policy that allow PutObject to any principal:

$ aws s3api --endpoint http://localhost:8084  put-bucket-policy --bucket policy-test --policy '{"Statement":{"Effect":"Allow","Principal":"*","Action":"s3:PutObject","Resource":"arn:aws:s3:::policy-test/*"}}'

Try put object using alternative credentials

$ aws s3api --endpoint http://localhost:8084 --profile alt   put-object  --bucket policy-test --key obj

An error occurred (AccessDenied) when calling the PutObject operation: Access Denied.

Context

This bug was found using s3-iam test

Regression

No

Your Environment

Version used: c334adeb6d
Server setup and configuration: dev-env

We cannot provide access to different user (in the same namespace) using [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html) ## Expected Behavior Different user can put object to our bucket ## Current Behavior Got error `AccessDenied` In logs: ``` 2024-02-07T12:07:43.516+0300 error handler/util.go:46 request failed {"status": 403, "request_id": "53e9c533-ef54-4bed-8d0a-fb930f2ed665", "method": "PutObject", "bucket": "policy-test", "object": "obj", "description": "could not get bucket settings", "error": "couldn't get node: access denied: access denied: rpc error: code = Unknown desc = access to operation GET is denied by extended ACL check: DENY eACL rule"} ``` ## Possible Solution Don't set eacl when create bucket but use APE rules to restrict access. ## Steps to Reproduce (for bugs) 1. Create bucket: ```shell $ aws s3api --endpoint http://localhost:8084 create-bucket --bucket policy-test ``` 2. Put bucket policy that allow `PutObject` to any principal: ```shell $ aws s3api --endpoint http://localhost:8084 put-bucket-policy --bucket policy-test --policy '{"Statement":{"Effect":"Allow","Principal":"*","Action":"s3:PutObject","Resource":"arn:aws:s3:::policy-test/*"}}' ``` 3. Try put object using alternative credentials ```shell $ aws s3api --endpoint http://localhost:8084 --profile alt put-object --bucket policy-test --key obj An error occurred (AccessDenied) when calling the PutObject operation: Access Denied. ``` ## Context This bug was found using s3-iam [test](https://git.frostfs.info/TrueCloudLab/s3-tests/src/commit/da91ad8bbf899c72199df35b69e9393c706aabee/s3tests_boto3/functional/test_iam.py#L516) ## Regression No ## Your Environment * Version used: https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/commit/c334adeb6da0bf6fa889b1bf8bb370ccc80f2b0e * Server setup and configuration: [dev-env](https://git.frostfs.info/TrueCloudLab/frostfs-dev-env)

dkirillov added the

bug

label 2024-02-07 09:12:38 +00:00

alexvanin commented

2024-02-08 14:47:58 +00:00

Owner

Right now our target is to replace eACL with new access policy engine (APE) rules to control access for buckets. Previously created buckets with s3-gw < v0.29.0 will remain affected by this issue. New buckets are going to be accessible if APE explicitly allows it.

Furthermore, we are looking to cooperate with AWS and restrict access for ACL operations. However, we do not intend to remove canned ACL for bucket settings. These ACLs worked fine in all previous s3-gw releases, so we intend to keep this functionality. Other less robust operations like put-object-acl are going to be restricted in favor of bucket policy control.

/cc @TrueCloudLab/architecture-committee

Right now our target is to replace eACL with new access policy engine (APE) rules to control access for buckets. Previously created buckets with s3-gw < v0.29.0 will remain affected by this issue. New buckets are going to be accessible if APE explicitly allows it. Furthermore, we are looking to [cooperate](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/) with AWS and restrict access for ACL operations. However, we do not intend to remove canned ACL for bucket settings. These ACLs worked fine in all previous s3-gw releases, so we intend to keep this functionality. Other less robust operations like `put-object-acl` are going to be restricted in favor of bucket policy control. /cc @TrueCloudLab/architecture-committee