[
https://issues.apache.org/jira/browse/HDFS-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056664#comment-14056664
]
Uma Maheswara Rao G commented on HDFS-6422:
-------------------------------------------
Thanks for summarizing pending things.
{quote}
that we should be validating xattr name access based on scan permission on the
inode's owning directory and xattr value access based on the inode's permission?
{quote}
For writing Xattrs, the current permissions covered. From your comment in list
Xattrs, we may need owner's check as well I think.
{code}
/* To access xattr names, you need EXECUTE in the owning directory. */
checkParentAccess(pc, src, FsAction.EXECUTE);
{code}
current check validates only execute permissions on parent dir. But it is not
caring whether you are owner for the current directory or not. What do you say?
For getXattrs, it will actually get the values there and it has pathaccess
check on inode. So, this should be fine. SetXattrs, RemoveXattrs treated as
writing xattrs and covered the permission checks appropriately as documented
for namespace categories.
> getfattr in CLI doesn't throw exception or return non-0 return code when
> xattr doesn't exist
> --------------------------------------------------------------------------------------------
>
> Key: HDFS-6422
> URL: https://issues.apache.org/jira/browse/HDFS-6422
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 3.0.0, 2.5.0
> Reporter: Charles Lamb
> Assignee: Charles Lamb
> Attachments: HDFS-6422.1.patch, HDFS-6422.2.patch, HDFS-6422.3.patch
>
>
> If you do
> hdfs dfs -getfattr -n user.blah /foo
> and user.blah doesn't exist, the command prints
> # file: /foo
> and a 0 return code.
> It should print an exception and return a non-0 return code instead.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
