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.
