Hi Kohei, Thank you for the feedback. The new approach will change the default "ACCESS" type group ACL numbers when a volume/bucket/key is created. These "ACCESS" type group ACLs cannot be inherited. The "DEFAULT" type group ACLs on the buckets/volumes, explicitly set by the users, will still be inherited by new keys. You can still limit actual permissions by setting proper Volume/Bucket ACLs through CLI.
Also Ozone supports set bucket ACL through s3g, https://issues.apache.org/jira/browse/HDDS-4550 https://issues.apache.org/jira/browse/HDDS-4585 Not sure If your concern is addressed. Bests, Sammi On Mon, 25 Nov 2024 at 16:47, Kohei Sugihara <ksugih...@preferred.jp> wrote: > Hi Sammi, > > We're running Ozone with Native ACL via S3 API. > > Reducing and limiting the default ACL is the correct and secure way. Still, > we're afraid that removing ALL and other groups from Key ACL affects some > permission issues via S3 because we do not have the Key ACL modification > API in the S3 interface. > All S3 requests must pass all Volume/Bucket/Key ACLs in the current > implementation. In this case, the loosed permission (the current behavior) > is useful as the default value because we can limit actual permission by > Volume/Bucket ACLs. > > We'd appreciate it if we have a switch for this behavior change or S3 API > respects to the bucket ACL for S3 instead of Volume/Bucket/Key ACL for the > upcoming release. > > Thanks, > Kohei > > 2024年11月19日(火) 23:16 Sammi Chen <sammic...@apache.org>: > > > Dear Ozone community developers and users, > > > > During a recent use case support, we found that when creating a new key, > > the current ozone client will create the default ACLs for the login user > > and all its groups, both with "ALL" privileges. This default behavior > has > > lead to two problems, > > > > (a). security unsafe. Say UserA is in the group “project A”, and “APAC > > employee". If UserA creates a new file for project A, then all other > users > > in the “APAC employee" group will have full control of this file, which > is > > usually not expected. > > > > (b). If a user is in hundreds of groups, then there will be hundreds of > ACL > > created, and saved as metadata of this key, which will consume > unnecessary > > network bandwidth, raft log, and rocksdb space. > > This is an example, the groups of my account in macOS, only few groups > are > > valuable to end users. > > "staff everyone localaccounts _appserverusr admin _appserveradm _lpadmin > > com.apple.sharepoint.group.2 com.apple.sharepoint.group.3 _appstore > > _lpoperator _developer _analyticsusers com.apple.access_ftp > > com.apple.access_screensharing com.apple.access_ssh > > com.apple.access_remote_ae com.apple.sharepoint.group.1" > > > > With JIRA HDDS-11656 <https://issues.apache.org/jira/browse/HDDS-11656> > , > > the default ACL behavior will change from currently creating an ACL with > > "ALL" permission for each group of the user, to only creating one ACL > with > > "READ, LIST" permission for the user's primary group. As for creating a > > "ALL" permission ACL for the user, it's not changed, and remains the > same. > > Use above UserA case as an example, if "project A" group is the primary > > group of this user, then when UserA created a new file, UserA will have > the > > full control of this file with ACL "ALL" permission, group "project A" > will > > have the read and list permission of this file, group “APAC employee" > will > > have no permission of this file. Since UserA has the full control of > this > > file, if the group “APAC employee" really needs to access this file, > UserA > > can explicitly add an ACL for the group “APAC employee" later. > > > > Native ACL is used by many community users. Please let me know if there > is > > any concern about this behavior change. > > > > > > Thanks, > > Sammi > > > > > -- > Kohei Sugihara, Engineer > Preferred Networks, Inc. >
