Thank you for the detailed explanation. On Tue, May 24, 2016 at 10:48 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote:
> Hello Kumar, > > I answered at the Stack Overflow link. I'll repeat the same information > here for everyone's benefit. > > HDFS implements the POSIX ACL model [1]. The linked documentation > explains that the mask entry is persisted into the group permission bits of > the classic POSIX permission model. This is done to support the > requirements of POSIX ACLs and also support backwards-compatibility with > existing tools like chmod, which are unaware of the extended ACL entries. > Quoting that document: > > > In minimal ACLs, the group class permissions are identical to the > > owning group permissions. In extended ACLs, the group class may > > contain entries for additional users or groups. This results in a > > problem: some of these additional entries may contain permissions that > > are not contained in the owning group entry, so the owning group entry > > permissions may differ from the group class permissions. > > > > This problem is solved by the virtue of the mask entry. With minimal > > ACLs, the group class permissions map to the owning group entry > > permissions. With extended ACLs, the group class permissions map to > > the mask entry permissions, whereas the owning group entry still > > defines the owning group permissions. > > > > ... > > > > When an application changes any of the owner, group, or other class > > permissions (e.g., via the chmod command), the corresponding ACL entry > > changes as well. Likewise, when an application changes the permissions > > of an ACL entry that maps to one of the user classes, the permissions > > of the class change. > > This is relevant to your question, because it means the mask is not in > fact persisted as an extended ACL entry. Instead, it's in the permission > bits. When querying WebHDFS, you've made a "raw" API call to retrieve > information about the ACL. When running getfacl, you've run an application > that layers additional display logic on top of that API call. getfacl is > aware that for a file with an ACL, the group permission bits are > interpreted as the mask, and so it displays accordingly. > > This is not specific to WebHDFS. If an application were to call > getAclStatus through the NameNode's RPC protocol, then it would see the > equivalent of the WebHDFS response. Also, if you were to use the getfacl > command on a webhdfs:// URI, then the command would still display the mask, > because the application knows to apply that logic regardless of the > FileSystem implementation. > > [1] http://www.vanemery.com/Linux/ACL/POSIX_ACL_on_Linux.html > > --Chris Nauroth > > From: kumar r <kumarc...@gmail.com> > Date: Monday, May 23, 2016 at 10:20 PM > To: "user@hadoop.apache.org" <user@hadoop.apache.org> > Subject: Mask value not shown in GETFACL using webhdfs > > Hi, > > In Hadoop, i have enabled authorization. I have set few acl for a > directory. > > When i execute getfacl command in hadoop bin, i can see mask value in that. > > hadoop fs -getfacl /Kumar > > # file: /Kumar > # owner: Kumar > # group: Hadoop > user::rwx > user:Babu:rwx > group::r-x > mask::rwx > other::r-x > > If i run the same command using webhdfs, mask value not shown. > > http://localhost:50070/webhdfs/v1/Kumar?op=GETACLSTATUS > > { > "AclStatus": { > "entries": [ > "user:Babu:rwx", > "group::r-x" > ], > "group": "Hadoop", > "owner": "Kumar", > "permission": "775", > "stickyBit": false > } > } > > What the reason for not showing mask value in webhdfs for GETFACL command? > > > Find the stack overflow question, > > > http://stackoverflow.com/questions/37404899/mask-value-not-shown-in-getfacl-using-webhdfs > > > Thanks, >
