hadoop-mapreduce-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kumar r <kumarc...@gmail.com>
Subject Re: Mask value not shown in GETFACL using webhdfs
Date Fri, 27 May 2016 09:16:46 GMT
Thank you for the detailed explanation.

On Tue, May 24, 2016 at 10:48 PM, Chris Nauroth <cnauroth@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 <kumarccpp@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,
>

Mime
View raw message