[
https://issues.apache.org/jira/browse/HDFS-14389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen O'Donnell updated HDFS-14389:
-------------------------------------
Status: Patch Available (was: Open)
> getAclStatus returns incorrect permissions and owner when an
> iNodeAttributeProvider is configured
> -------------------------------------------------------------------------------------------------
>
> Key: HDFS-14389
> URL: https://issues.apache.org/jira/browse/HDFS-14389
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 3.2.0
> Reporter: Stephen O'Donnell
> Assignee: Stephen O'Donnell
> Priority: Major
> Fix For: 3.2.0
>
> Attachments: HDFS-14389.001.patch
>
>
> 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:
> {code}
> 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
> {code}
> 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:
> {code}
> 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
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
