hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen O'Donnell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HDFS-14389) getAclStatus returns incorrect permissions and owner when an iNodeAttributeProvider is configured
Date Sun, 24 Mar 2019 14:46:00 GMT
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:

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:hive:rwx   #effective:r--
group:sentryDefaultAdmin:rwx    #effective:r--
user:admin:rwx  #effective:r--
group:systest:rwx       #effective:r--
group:hive:rwx  #effective:r--

Note the effective comment, indicating group permissions of r-- which the ls output does not

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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

View raw message