Configurable default group ACL for newly created keys

[Pigueiras]

Hello again 😄 ,

We are running into an ACL issue in a Kerberized Ozone cluster using OzoneNativeAuthorizer and LDAP group mapping.

When a user creates a key, Ozone automatically adds a default ACL for the user's primary group. In our setup, that primary group comes from Hadoop UserGroupInformation#getPrimaryGroupName(), which is effectively the first
group returned by the LDAP group mapping.

The specific Ozone code path is OzoneAclUtil#getDefaultAclList(), where the group ACL is built from ugi.getPrimaryGroupName():

ozone/hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/helpers/OzoneAclUtil.java

Lines 62 to 74 in ea8762e

	public static List<OzoneAcl> getDefaultAclList(UserGroupInformation ugi, OzoneConfiguration conf) {
	// Get default acl rights for user and group.
	if (userRights == null || groupRights == null) {
	OzoneAclConfig aclConfig = conf.getObject(OzoneAclConfig.class);
	userRights = aclConfig.getUserDefaultRights();
	groupRights = aclConfig.getGroupDefaultRights();
	}
	List<OzoneAcl> listOfAcls = new ArrayList<>();
	// User ACL.
	listOfAcls.add(new OzoneAcl(USER, ugi.getShortUserName(), ACCESS, userRights));
	try {
	String groupName = ugi.getPrimaryGroupName();
	listOfAcls.add(new OzoneAcl(GROUP, groupName, ACCESS, groupRights));

For example, a newly created key may get:

{
  "type": "GROUP",
  "name": "some-user-group",
  "aclScope": "ACCESS",
  "aclList": [ "READ", "LIST" ]
}

The problem is that, with LDAP/AD groups, this "primary group" can be somewhat arbitrary from the storage-admin point of view. It may be an unrelated egroup, and then every member of that group receives default access to newly created keys.

We tried setting:

<property>
  <name>ozone.om.group.rights</name>
  <value>NONE</value>
</property>

but this has an unfortunate interaction with inherited DEFAULT ACLs. If the same group is also granted by a bucket DEFAULT ACL, the final ACL can become:

{
  "type": "GROUP",
  "name": "some-group",
  "aclScope": "ACCESS",
  "aclList": [ "ALL", "NONE" ]
}

Since NONE is treated as an explicit deny, it overrides the inherited ALL. So this is not a good workaround either.

Using READ_ACL instead of NONE reduces the data-access risk, but it still creates an ACL for a group that the bucket owner did not intentionally choose.

Would the project be open to a PR adding a configuration option to control this behavior?

Possible approaches:

1. Add a boolean to disable creation of the default primary-group ACL, for example:

   <name>ozone.om.default.group.acl.enabled</name>
   <value>false</value>

2. Allow ozone.om.group.rights to be empty and interpret that as "do not add a group ACL".

3. Add a configurable default group name, so deployments can force the group ACL to a known harmless group instead of UserGroupInformation#getPrimaryGroupName().

From our side, option 1 looks cleanest: keep the existing behavior by default, but allow operators to opt out of automatic primary-group ACL creation.

Before we work on a PR, is there already another recommended way to solve this?
Or would such a change be acceptable upstream?

Thanks a lot 👍

[ChenSammi]

Ozone uses the same user/group management class as Hadoop. If LDAP is used, have you already tried set the property "hadoop.security.group.mapping" to "org.apache.hadoop.security.LdapGroupsMapping", along with a few LDAP connection configurations? FYI, https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/GroupsMapping.html#LDAP_Groups_Mapping.

If you have already configured LDAP correctly, the only problem is you cannot control the right primary group of user is returned first by LDAP, then first approach, enable/disable default group ACL creation looks OK to me.

[Pigueiras]

Yes, LDAP group mapping is already configured and Ozone is receiving the LDAP groups. The issue is not missing group mapping, but that the first group returned by ldap is not always a group that makes sense to include it in the ACLs.

For context, with HDFS we were using our own ldap resolver, so we could control this behavior and did not run into the same problem. With Ozone relying on UserGroupInformation#getPrimaryGroupName() for the default group ACL, the chosen group can be unrelated from a storage-policy point of view.

Given that, we'll see if we can prepare a PR for option 1: keep the current behavior by default, but add a config to skip creation of the automatic primary-group ACL 😄