You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Srikanth Upputuri (JIRA)" <ji...@apache.org> on 2015/02/16 10:13:12 UTC

[jira] [Commented] (HDFS-6962) ACLs inheritance conflict with umaskmode

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

Srikanth Upputuri commented on HDFS-6962:
-----------------------------------------

[~cnauroth], after reading your comment above I have studied the relevant code and this is what I think. 

The umask should be loaded and applied on the server, depending on whether the parent directory has default acls or not. Only if default acls do not exist, umask will be applied to the mode. For mode, client will either pass the source permissions(cp, put, copyFromLocal) or the default permissions if no source permissions exist(create, mkdir etc). Currently the client code wrongly applies the mask to the permissions before making RPC calls. This happens at several places and this needs to be changed. 

For the copyFromLocal command, I have compared the behavior with 'cp' on Linux local file system. The resultant permissions of the destination file are determined by the parent directory's default permissions and the source file's permissions (mode). The umask is used only when the parent directory doesn't have default permissions. This is just like create api, except that in case of 'create', the mode takes default value (0666).
The second RPC to 'setPermission' is only used when 'preserve attributes' option -p is used and permissions/ACLs are expected to be retained and in this case umask is not required. So, the only change 'copyFromLocal' may require is pass the the source file's permissions as mode, without masking.

Compatibility: Older clients applying the mask before passing the mode to server will retain their existing behavior if the parent directory has default permissions. In case the parent directory does not have default permissions, the mask gets applied one more time on the server without causing any change to the permissions. So, effectively the clients see the same behavior as existing.

I am attaching a prototype patch, please take a look. I will add tests later once the approach is validated.

> ACLs inheritance conflict with umaskmode
> ----------------------------------------
>
>                 Key: HDFS-6962
>                 URL: https://issues.apache.org/jira/browse/HDFS-6962
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.4.1
>         Environment: CentOS release 6.5 (Final)
>            Reporter: LINTE
>            Assignee: Srikanth Upputuri
>              Labels: hadoop, security
>
> In hdfs-site.xml 
> <property>
>     <name>dfs.umaskmode</name>
>     <value>027</value>
> </property>
> 1/ Create a directory as superuser
> bash# hdfs dfs -mkdir  /tmp/ACLS
> 2/ set default ACLs on this directory rwx access for group readwrite and user toto
> bash# hdfs dfs -setfacl -m default:group:readwrite:rwx /tmp/ACLS
> bash# hdfs dfs -setfacl -m default:user:toto:rwx /tmp/ACLS
> 3/ check ACLs /tmp/ACLS/
> bash# hdfs dfs -getfacl /tmp/ACLS/
> # file: /tmp/ACLS
> # owner: hdfs
> # group: hadoop
> user::rwx
> group::r-x
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> user::rwx | group::r-x | other::--- matches with the umaskmode defined in hdfs-site.xml, everything ok !
> default:group:readwrite:rwx allow readwrite group with rwx access for inhéritance.
> default:user:toto:rwx allow toto user with rwx access for inhéritance.
> default:mask::rwx inhéritance mask is rwx, so no mask
> 4/ Create a subdir to test inheritance of ACL
> bash# hdfs dfs -mkdir  /tmp/ACLS/hdfs
> 5/ check ACLs /tmp/ACLS/hdfs
> bash# hdfs dfs -getfacl /tmp/ACLS/hdfs
> # file: /tmp/ACLS/hdfs
> # owner: hdfs
> # group: hadoop
> user::rwx
> user:toto:rwx   #effective:r-x
> group::r-x
> group:readwrite:rwx     #effective:r-x
> mask::r-x
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> Here we can see that the readwrite group has rwx ACL bu only r-x is effective because the mask is r-x (mask::r-x) in spite of default mask for inheritance is set to default:mask::rwx on /tmp/ACLS/
> 6/ Modifiy hdfs-site.xml et restart namenode
> <property>
>     <name>dfs.umaskmode</name>
>     <value>010</value>
> </property>
> 7/ Create a subdir to test inheritance of ACL with new parameter umaskmode
> bash# hdfs dfs -mkdir  /tmp/ACLS/hdfs2
> 8/ Check ACL on /tmp/ACLS/hdfs2
> bash# hdfs dfs -getfacl /tmp/ACLS/hdfs2
> # file: /tmp/ACLS/hdfs2
> # owner: hdfs
> # group: hadoop
> user::rwx
> user:toto:rwx   #effective:rw-
> group::r-x      #effective:r--
> group:readwrite:rwx     #effective:rw-
> mask::rw-
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> So HDFS masks the ACL value (user, group and other  -- exepted the POSIX owner -- ) with the group mask of dfs.umaskmode properties when creating directory with inherited ACL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)