aws s3api list-objects might list objects in bucket owned by different credentials for a short period of time #335

New issue

Closed

opened 2025-12-28 17:37:02 +00:00 by sami · 2 comments

sami commented

2025-12-28 17:37:02 +00:00

Owner

Originally created by @lesnya on GitHub (Sep 22, 2022).

Originally assigned to: @KirillovDenis on GitHub.

Steps to reproduce:

Create two different wallets (let's say wallet_user1.json and wallet_user2.json).
Issue two sets of s3 keys by neofs-s3-authmate issue-secret - one for wallet_user1.json and another one for wallet_user2.json
Configure two aws clients using these two different sets of s3 keys.
Create bucket using user1's aws credentials:
aws --no-verify-ssl s3api create-bucket --bucket acl-test-user1 --endpoint-url http://node1.neofs:8084
List objects in this bucket using user2's aws credentials from another terminal - an error should be received as an output. This is expected behaviour.
aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://172.19.17.229:8084 An error occurred (InternalError) when calling the ListObjects operation (reached max retries: 2): failed to get sub tree: rpc error: code = Unknown desc = bearer token must be signed by the container owner
Put any object in this bucket using user1's aws credentials:
aws --no-verify-ssl s3api put-object --bucket acl-test-user1 --key user1-owner-data --body /tmp/data.txt --endpoint-url http://node1.neofs:8084
List objects in this bucket using user1's aws credentials:
aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://node1.neofs:8084
Immediately after, list objects in this bucket using user2's aws credentials from another terminal:
aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://172.19.17.229:8084
This time command will return the list of objects for this owned by user1's bucket, although it was executed from user2's credentials.
You can re-run command above multiple times - each time it will return the list of objects.
This behaviour will persist for about 10-16 seconds.
After this period of time the command will start getting an error from step 5 again, as expected.
You can go and repeat all steps starting from step 6 to reproduce the issue.

NOTE:
a) If you skip step 7, command in step 8 will return an error, as it should.
b) If use any other endpoint in command from step 8, it will return an error, too.

Cache?

Originally created by @lesnya on GitHub (Sep 22, 2022). Originally assigned to: @KirillovDenis on GitHub. Steps to reproduce: 1. Create two different wallets (let's say wallet_user1.json and wallet_user2.json). 2. Issue two sets of s3 keys by neofs-s3-authmate issue-secret - one for wallet_user1.json and another one for wallet_user2.json 3. Configure two aws clients using these two different sets of s3 keys. 4. Create bucket using user1's aws credentials: `aws --no-verify-ssl s3api create-bucket --bucket acl-test-user1 --endpoint-url http://node1.neofs:8084` 5. List objects in this bucket using user2's aws credentials from another terminal - an error should be received as an output. This is expected behaviour. `aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://172.19.17.229:8084 An error occurred (InternalError) when calling the ListObjects operation (reached max retries: 2): failed to get sub tree: rpc error: code = Unknown desc = bearer token must be signed by the container owner` 6. Put any object in this bucket using user1's aws credentials: `aws --no-verify-ssl s3api put-object --bucket acl-test-user1 --key user1-owner-data --body /tmp/data.txt --endpoint-url http://node1.neofs:8084` 7. List objects in this bucket using user1's aws credentials: `aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://node1.neofs:8084` 8. Immediately after, list objects in this bucket using user2's aws credentials from another terminal: `aws --no-verify-ssl s3api list-objects --bucket acl-test-user1 --endpoint-url http://172.19.17.229:8084` 9. This time command will return the list of objects for this owned by user1's bucket, although it was executed from user2's credentials. 10. You can re-run command above multiple times - each time it will return the list of objects. 11. This behaviour will persist for about 10-16 seconds. 12. After this period of time the command will start getting an error from step 5 again, as expected. 13. You can go and repeat all steps starting from step 6 to reproduce the issue. NOTE: a) If you skip step 7, command in step 8 will return an error, as it should. b) If use any other endpoint in command from step 8, it will return an error, too. Cache?

sami

2025-12-28 17:37:02 +00:00

closed this issue
added the
bug

config

U2
labels

sami commented

2025-12-28 17:37:03 +00:00

Author

Owner

@KirillovDenis commented on GitHub (Sep 23, 2022):

Cache?

Yes

@KirillovDenis commented on GitHub (Sep 23, 2022): > Cache? Yes

sami commented

2025-12-28 17:37:03 +00:00

Author

Owner

@alexvanin commented on GitHub (Oct 3, 2022):

To solve this issue we need to introduce access control cache. This LRU cache should store successful or unsuccessful attempts to receive the data from storage, considering access control errors. This cache should evict values whithin configured timeout, because access control rules may change over time, so we want to drop cache data over time.

@alexvanin commented on GitHub (Oct 3, 2022): To solve this issue we need to introduce access control cache. This LRU cache should store successful or unsuccessful attempts to receive the data from storage, considering access control errors. This cache should evict values whithin configured timeout, because access control rules may change over time, so we want to drop cache data over time.