list-object fails when user with supplemental group access put object to the bucket

[nadavMiz]

Environment info

• NooBaa Version: VERSION
• Platform: Kubernetes 1.14.1 | minikube 1.1.1 | OpenShift 4.1 | other: specify

Actual behavior

1.when a user with supplemental group access put an object to a bucket he has access to, the bucket owner can't list objects for the bucket because he doesn't have access to the objects added by the other user

Expected behavior

1. list-object shows all objects in the bucket or at least doesn't fail

Steps to reproduce

1. create a new bucket by a user (for examplw uid:2002, gid:2002) using s3 command:
   s3api_user1 create-bucket --bucket test-bucket
2. create a new user with different uid gid, but with supplemental group access to the bucket (2002 as supplemental group):
   sudo node src/cmd/manage_nsfs account add --name test_user2 --uid 1002 --gid 1002 --suplemental_groups 2002
3. add new object by the new user:
   s3api_user2 put-object --bucket test-bucket --key key1
4. list objects of the new bucket by user1
   s3api_user1 list-objects --bucket test-bucket

More information - Screenshots / Logs / Other output

following are logs of the presented issue. in the following case there are two users: danny and jane. danny is the bucket owner and jane is a user with supplemental group access to the bucket. in this case both users put object successfully to the bucket. danny (the bucket owner fails to list objects of the bucket)

Jan-23 15:50:03.396 [nsfs/391543]    [L1] core.sdk.namespace_fs:: check_bucket_boundaries: fs_context { uid: 1000, gid: 1001, new_buckets_path: '/home/nadav/Desktop/buckets/', backend: '', warn_threshold_ms: 100, report_fs_stats: [Function (anonymous)] } file_path /home/nadav/Desktop/buckets/danny-bucket/jane-key this.bucket_path /home/nadav/Desktop/buckets/danny-bucket
2025-01-23 15:50:03.396351 [PID-391543/TID-391573] [L1] FS::FSWorker::Execute: RealPath _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key  took: 0.025674 ms2025-01-23 15:50:03.396358 [PID-391543/TID-391543] [L1] FS::FSWorker::Begin: RealPath _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key 

2025-01-23 15:50:03.396405 [PID-391543/TID-391571] [L1] FS::FSWorker::Execute: RealPath _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key _uid=1000 _gid=1001 _backend= supplemental_groups= 
2025-01-23 15:50:03.396439 [PID-391543/TID-391543] [L1] FS::RealPath::OnOK: _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key _full_path=/home/nadav/Desktop/buckets/danny-bucket/danny-key 
2025-01-23 15:50:03.396490 [PID-391543/TID-391571] [L1] FS::FSWorker::Execute: RealPath _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key _uid=1000 _gid=1001 geteuid()=1000 getegid()=1001 getuid()=0 getgid()=0 new_supplemental_groups= 
2025-01-23 15:50:03.396562 [PID-391543/TID-391571] [L1] FS::FSWorker::Execute: RealPath _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key  took: 0.041718 ms
2025-01-23 15:50:03.396650 [PID-391543/TID-391543] [L1] FS::FSWorker::Begin: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key 
2025-01-23 15:50:03.396692 [PID-391543/TID-391543] [L1] FS::RealPath::OnOK: _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key _full_path=/home/nadav/Desktop/buckets/danny-bucket/jane-key 
2025-01-23 15:50:03.396687 [PID-391543/TID-391574] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key _uid=1000 _gid=1001 _backend= supplemental_groups= 
2025-01-23 15:50:03.396775 [PID-391543/TID-391574] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key _uid=1000 _gid=1001 geteuid()=1000 getegid()=1001 getuid()=0 getgid()=0 new_supplemental_groups= 
2025-01-23 15:50:03.396845 [PID-391543/TID-391543] [L1] FS::FSWorker::Begin: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key 
2025-01-23 15:50:03.396896 [PID-391543/TID-391572] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key _uid=1000 _gid=1001 _backend= supplemental_groups= 2025-01-23 15:50:03.396913 [PID-391543/TID-391574] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key  took: 0.104984 ms

2025-01-23 15:50:03.396968 [PID-391543/TID-391543] [L1] FS::Stat::OnOK: _path=/home/nadav/Desktop/buckets/danny-bucket/danny-key _stat_res.st_ino=537361547 _stat_res.st_size=0 
2025-01-23 15:50:03.397023 [PID-391543/TID-391572] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key _uid=1000 _gid=1001 geteuid()=1000 getegid()=1001 getuid()=0 getgid()=0 new_supplemental_groups= 
2025-01-23 15:50:03.397080 [PID-391543/TID-391572] [L1] FS::FSWorker::Execute: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key  took: 0.032198 ms
2025-01-23 15:50:03.397166 [PID-391543/TID-391543] [L1] FS::FSWorker::OnError: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key  error.Message()=Permission denied 
Jan-23 15:50:03.398 [nsfs/391543] [ERROR] core.endpoint.s3.s3_rest:: S3 ERROR <?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><Message>Access Denied</Message><Resource>/danny-bucket?encoding-type=url</Resource><RequestId>m69e41u4-edufpu-3v6</RequestId></Error> GET /danny-bucket?encoding-type=url {"host":"localhost:6443","accept-encoding":"identity","user-agent":"aws-cli/2.15.28 Python/3.11.8 Linux/4.18.0-553.33.1.el8_10.x86_64 exe/x86_64.rhel.8 prompt/off command/s3api.list-objects","x-amz-date":"20250123T135003Z","x-amz-content-sha256":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855","authorization":"AWS4-HMAC-SHA256 Credential=02XTJHcloaosrDpvdDtd/20250123/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=3e183a2127c819c5cb0813b2f45b51e280db2d7f313ed43e2a0844ce7f29c400"} Error: Permission denied - context: Stat _path=/home/nadav/Desktop/buckets/danny-bucket/jane-key
2025-01-23 15:50:03.401450 [PID-391543/TID-391543] [L1] FS::FSWorker::Begin: Stat _path=/etc/noobaa.conf.d/buckets/danny-bucket.json 
2025-01-23 15:50:03.401511 [PID-391543/TID-391573] [L1] FS::FSWorker::Execute: Stat _path=/etc/noobaa.conf.d/buckets/danny-bucket.json _uid=0 _gid=0 _backend= supplemental_groups= 
2025-01-23 15:50:03.401566 [PID-391543/TID-391573] [L1] FS::FSWorker::Execute: Stat _path=/etc/noobaa.conf.d/buckets/danny-bucket.json _uid=0 _gid=0 geteuid()=0 getegid()=0 getuid()=0 getgid()=0 new_supplemental_groups=0 
2025-01-23 15:50:03.401659 [PID-391543/TID-391573] [L1] FS::FSWorker::Execute: Stat _path=/etc/noobaa.conf.d/buckets/danny-bucket.json  took: 0.072898 ms
2025-01-23 15:50:03.402891 [PID-391543/TID-391543] [L1] FS::Stat::OnOK: _path=/etc/noobaa.conf.d/buckets/danny-bucket.json _stat_res.st_ino=271438424 _stat_res.st_size=406 

[nadavMiz]

FYI @naveenpaul1 , probably related to #8293

[naveenpaul1]

@nadavMiz we can list the object added by other user using supplemental group, right?

[nadavMiz]

@naveenpaul1 the user with supplemental group access can list all objects as he has access to both his objects, and to the other user objects via having his group as supplemental group.
the bucket owner can only access the objects he put, because he doesn't have the other users group as a supplemental group. if you add the other user group as a supplemental group to the bucket owner then he will be able to access his objects as well

[nadavMiz]

@guymguym @romayalon @naveenpaul1 not sure if its a valid idea. but at least in this case, if we at least give new objects the group of the bucket rather then the group of the user then all users with group access to the bucket will be able to access all objects in the bucket. this will be similar to how mac handles new directories where it gives the new directory the uid of the process, but the gid of the parent directory. see #8665 macos documentation of mkdir

[romayalon]

@nadavMiz we need to be compatible with S3, please read more here about object owners - https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html.
According to https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-retrieving.html
There are 2 options for object owner -
Bucket owner (default, ACL disabled)
Object writer (ACLs enabled)
Seems like we need to set the owner of the object to be the bucket owner and not the object writer as long we don't support ACLs.
When starting to support ACLs we would need to be able to set that as well, but in any case we need to decide in general on how to handle failures of access to a specific object, how would AWS behave?
another option is if the request executer is the owner of the bucket, we shouldn't fail on EACCESS/EPERM