[ https://issues.apache.org/jira/browse/HDFS-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043753#comment-14043753 ]
Chris Nauroth commented on HDFS-6556: ------------------------------------- Hi, [~umamaheswararao]. The patch looks good. I have one minor suggestion. I see this code block is repeated in {{FSNamesystem#setXAttrInt}} and {{FSNamesystem#removeXAttr}}: {code} if (isPermissionEnabled && xAttr.getNameSpace() == XAttr.NameSpace.USER) { if (isStickyBitDirectory(src)) { if (!pc.isSuperUser()) { checkOwner(pc, src); } } else { checkPathAccess(pc, src, FsAction.WRITE); } } {code} We could remove the {{isStickyBitDirectory}} method and instead add a method named something like {{checkXAttrChangeAccess}} that fully encapsulates all of the above logic. This would reduce code duplication. What do you think? > Refine XAttr permissions > ------------------------ > > Key: HDFS-6556 > URL: https://issues.apache.org/jira/browse/HDFS-6556 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Affects Versions: 2.5.0 > Reporter: Yi Liu > Assignee: Uma Maheswara Rao G > Attachments: RefinedPermissions-HDFS-6556-1.patch, > RefinedPermissions-HDFS-6556.patch, refinedPermissions-HDFS-6556-2.patch > > > After discuss with Uma, we should refine setting permissions of {{user}} and > {{trusted}} namespace xattrs. > *1.* For {{user}} namespace xattrs, In HDFS-6374, says "setXAttr should > require the user to be the owner of the file or directory", we have a bit > misunderstanding. It actually is: > {quote} > The access permissions for user attributes are defined by the file permission > bits. only regular files and directories can have extended attributes. For > sticky directories, only the owner and privileged user can write attributes. > {quote} > We can refer to linux source code in > http://lxr.free-electrons.com/source/fs/xattr.c?v=2.6.35 > I also check in linux, it's controlled by the file permission bits for > regular files and directories (not sticky). > *2.* For {{trusted}} namespace, currently we require the user should be owner > and superuser. Actually superuser is enough. -- This message was sent by Atlassian JIRA (v6.2#6252)