Details
Major Description
With an inodeAttributeProvider configured in the namenode (eg Sentry), the permissions returned by a `hadoop fs -getfacl` command have an effective comment after them, even if the group permission bits are rwx, eg:
hadoop fs -ls /user/hive/warehouse/sample_08 Found 1 items -rwxrwx--x+ 3 hive hive 46069 2019-03-22 00:19 /user/hive/warehouse/sample_08/sample_08 NOTE THE GROUP PERMISSIONS - rwx - No ACLs should get masked. hadoop fs -getfacl /user/hive/warehouse/sample_08/sample_08 # file: /user/hive/warehouse/sample_08/sample_08 # owner: hive # group: hive user::rwx group::--- user:hive:rwx #effective:r-- group:sentryDefaultAdmin:rwx #effective:r-- user:admin:rwx #effective:r-- group:systest:rwx #effective:r-- group:hive:rwx #effective:r-- mask::rwx other::--x
Note the effective comment, indicating group permissions of r-- which the ls output does not show.
Usually this effective comment would downgrade the effective permissions, and a user with the group systest would not be able to write to the file / folder, but in this case that does not happen - this appears to be a display issue in the client.
After some debugging, the problem is due to getAclStatus returning the permissions, owner and group of the underlying file in HDFS and not those from the inodeAttributeProvider - ie this call does not correctly use the attribute provider. Comparing the output with getFileStatus:
Permission from FileStatus: rwxrwx--x # Correct, the provider says the permissions are 771
Permission from AclStatus: rw-r--r-- # Incorrect, these are the permissions from HDFS if the provided is disabled
Note that in this example, the underlying file permissions have group r--, and that is what is influencing the ACL output, making them effective r--.
Within the namenode, the permissions are enforced correctly. The reason this is a CLI display issue is that AclCommand.java makes a call to getAclStatus, and from it, it gets the ACL list and the group permissions. Then it 'masks' the ACLs it displays using the returned group permission within the client. This is only for display purposes. FSPermissionChecker inside the Namenode is not impacted by this and does the correct thing.