Stephen O'Donnell created HDFS-14389:
----------------------------------------
Summary: 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
Fix For: 3.2.0
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]
