Changing canned ACL from public-read-write to public-read doesn't work #316

Closed
opened 2024-02-19 08:23:43 +00:00 by dkirillov · 3 comments
Member

Changing canned ACL from public-read-write to public-read doesn't work

Expected Behavior

Setting bucket acl to public-read after public-read-write forbid non bucket owner to put objects.

Current Behavior

Non owner still can put object to the bucket.

Possible Solution

Revise mergeAst function.
The problem: to find if diff between current and wanted "AST" exists we go through all new ast operation and finds them in current. If current fully contains wanted we don't do anything. But in case of changing acl from public-read-write to public-read this isn't correct because we must consider missing operations in wanted "ast" as deny.

Steps to Reproduce (for bugs)

  1. Create public-read-write bucket:
$ aws s3api --endpoint http://localhost:8084 create-bucket --bucket test-acl --acl public-read-write
  1. Make sure bucket is public read write:
$ aws s3api --endpoint http://localhost:8084 put-object --bucket test-acl --key tmp --profile alt 
{
    "ETag": "\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\""
}
  1. Change acl to public-read:
$ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl public-read
  1. Try to put object using non owner creds again. Error is expected:
$ aws s3api --endpoint http://localhost:8084 put-object --bucket test-acl --key tmp --profile alt 
{
    "ETag": "\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\""
}

Workaround

Set private acl first:

$ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl private

$ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl public-read

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

An error occurred (AccessDenied) when calling the PutObject operation (reached max retries: 0): Access Denied.

Regression

I'm not sure

Your Environment

  • Version used: cc34f659d1
  • Server setup and configuration: devenv
Changing canned ACL from `public-read-write` to `public-read` doesn't work ## Expected Behavior Setting bucket acl to `public-read` after `public-read-write` forbid non bucket owner to put objects. ## Current Behavior Non owner still can put object to the bucket. ## Possible Solution Revise [mergeAst](https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/src/commit/bd8d2d00ba466fe76755d6da6b3c26d892643ba9/api/handler/acl.go#L829) function. The problem: to find if diff between current and wanted "AST" exists we go through all new ast operation and finds them in current. If current fully contains wanted we don't do anything. But in case of changing acl from `public-read-write` to `public-read` this isn't correct because we must consider missing operations in wanted "ast" as deny. ## Steps to Reproduce (for bugs) 1. Create `public-read-write` bucket: ``` $ aws s3api --endpoint http://localhost:8084 create-bucket --bucket test-acl --acl public-read-write ``` 2. Make sure bucket is public read write: ``` $ aws s3api --endpoint http://localhost:8084 put-object --bucket test-acl --key tmp --profile alt { "ETag": "\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\"" } ``` 3. Change acl to public-read: ``` $ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl public-read ``` 4. Try to put object using non owner creds again. Error is expected: ``` $ aws s3api --endpoint http://localhost:8084 put-object --bucket test-acl --key tmp --profile alt { "ETag": "\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\"" } ``` ### Workaround Set `private` acl first: ``` $ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl private $ aws s3api --endpoint http://localhost:8084 put-bucket-acl --bucket test-acl --acl public-read $ aws s3api --endpoint http://localhost:8084 put-object --bucket test-acl --key tmp --profile alt An error occurred (AccessDenied) when calling the PutObject operation (reached max retries: 0): Access Denied. ``` ## Regression I'm not sure ## Your Environment <!--- Include as many relevant details about the environment you experienced the bug in --> * Version used: https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/commit/cc34f659d17c314cc3273023e874b6c73d1744fe * Server setup and configuration: devenv
dkirillov added the
bug
label 2024-02-19 08:23:43 +00:00
Owner

As far as I understand, #306 is going to fix it for all new buckets, right?

As far as I understand, https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/issues/306 is going to fix it for all new buckets, right?
Author
Member

As far as I understand, #306 is going to fix it for all new buckets, right?

yes

> As far as I understand, https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/issues/306 is going to fix it for all new buckets, right? yes
Owner

Closed due to #306.

Closed due to #306.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-s3-gw#316
No description provided.