You are viewing a plain text version of this content. The canonical link for it is here.

Posted to hdfs-dev@hadoop.apache.org by John Zhuge <jz...@cloudera.com> on 2016/09/19 17:55:48 UTC

Permission bit 12 in getFileInfo response

Hi Gurus,

Does anyone know the meaning of bit 12 in the permission field of
"getFileInfo" response? To my understanding, the bit 9 is sticky bit, along
with the lower 9 bits for user/group/other.

In this following trace, the "perm" field is "4584", i.e., "10750" in oct:

16/09/15 15:54:56 TRACE ipc.ProtobufRpcEngine: 1: Response <-
NAMENODE:8020: getFileInfo {fs { fileType: IS_DIR path: "" length: 0
permission { perm: 4584 } owner: "USER" group: "supergroup"
modification_time: 1473884314570 access_time: 0 block_replication: 0
blocksize: 0 fileId: 8798130 childrenNum: 1 storagePolicy: 0 }}

Thanks,
John Zhuge
Software Engineer, Cloudera

Re: Permission bit 12 in getFileInfo response

Posted by John Zhuge <jz...@cloudera.com>.

Thanks Chris!  Silly me, didn't look at "FsPermissionExtension".

John Zhuge
Software Engineer, Cloudera

On Mon, Sep 19, 2016 at 11:33 AM, Chris Nauroth <cn...@hortonworks.com>
wrote:

> Hello John,
>
> That is the ACL bit.  The NameNode toggles on the ACL bit in getFileInfo
> responses for inodes that have ACL entries attached to them.  On the client
> side, this results in calls to FsPermission#getAclBit returning true.
>
> The purpose of the ACL bit is to help client applications identify files
> and directories that have ACL entries attached.  One specific example where
> this is useful is in the output of the file system shell "ls" command.
> (See org.apache.hadoop.fs.shell.Ls#processPath.)  If the ACL bit is
> turned on, then this is how the shell decides to append a '+' character
> after the basic permissions, so the end user knows that ACL entries are
> present.  If the ACL bit didn’t exist, then applications like this would
> have to be implemented with a more costly FileSystem#getAclStatus call, in
> addition to the existing getFileInfo RPC.
>
> Test cases defined in FSAclBaseTest check for the presence of the ACL bit
> where expected.
>
> --Chris Nauroth
>
> On 9/19/16, 10:55 AM, "John Zhuge" <jz...@cloudera.com> wrote:
>
>     Hi Gurus,
>
>     Does anyone know the meaning of bit 12 in the permission field of
>     "getFileInfo" response? To my understanding, the bit 9 is sticky bit,
> along
>     with the lower 9 bits for user/group/other.
>
>     In this following trace, the "perm" field is "4584", i.e., "10750" in
> oct:
>
>     16/09/15 15:54:56 TRACE ipc.ProtobufRpcEngine: 1: Response <-
>     NAMENODE:8020: getFileInfo {fs { fileType: IS_DIR path: "" length: 0
>     permission { perm: 4584 } owner: "USER" group: "supergroup"
>     modification_time: 1473884314570 access_time: 0 block_replication: 0
>     blocksize: 0 fileId: 8798130 childrenNum: 1 storagePolicy: 0 }}
>
>     Thanks,
>     John Zhuge
>     Software Engineer, Cloudera
>
>
>

Re: Permission bit 12 in getFileInfo response

Posted by Chris Nauroth <cn...@hortonworks.com>.

Hello John,

That is the ACL bit. The NameNode toggles on the ACL bit in getFileInfo responses for inodes that have ACL entries attached to them. On the client side, this results in calls to FsPermission#getAclBit returning true.

The purpose of the ACL bit is to help client applications identify files and directories that have ACL entries attached. One specific example where this is useful is in the output of the file system shell "ls" command. (See org.apache.hadoop.fs.shell.Ls#processPath.) If the ACL bit is turned on, then this is how the shell decides to append a '+' character after the basic permissions, so the end user knows that ACL entries are present. If the ACL bit didn’t exist, then applications like this would have to be implemented with a more costly FileSystem#getAclStatus call, in addition to the existing getFileInfo RPC.

Test cases defined in FSAclBaseTest check for the presence of the ACL bit where expected.

--Chris Nauroth

On 9/19/16, 10:55 AM, "John Zhuge" <jz...@cloudera.com> wrote:

Hi Gurus,

Does anyone know the meaning of bit 12 in the permission field of
"getFileInfo" response? To my understanding, the bit 9 is sticky bit, along
with the lower 9 bits for user/group/other.

In this following trace, the "perm" field is "4584", i.e., "10750" in oct:

16/09/15 15:54:56 TRACE ipc.ProtobufRpcEngine: 1: Response <-
NAMENODE:8020: getFileInfo {fs { fileType: IS_DIR path: "" length: 0
permission { perm: 4584 } owner: "USER" group: "supergroup"
modification_time: 1473884314570 access_time: 0 block_replication: 0
blocksize: 0 fileId: 8798130 childrenNum: 1 storagePolicy: 0 }}

Thanks,
John Zhuge
Software Engineer, Cloudera