hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-14389) getAclStatus returns incorrect permissions and owner when an iNodeAttributeProvider is configured
Date Mon, 25 Mar 2019 13:34:00 GMT

    [ https://issues.apache.org/jira/browse/HDFS-14389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800682#comment-16800682

Wei-Chiu Chuang commented on HDFS-14389:

Makes sense to me.
bq. This is only for display purposes.
I'm not sure if this is true. This method is used by {{NameNodeRpcServer#getAclStatus}}, which
is called by {{DistributedFileSystem#getAclStatus}} which is used by  distcp. Distcp may update
ACLs incorrectly as a result.

> getAclStatus returns incorrect permissions and owner when an iNodeAttributeProvider is
> -------------------------------------------------------------------------------------------------
>                 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
> 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

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

View raw message