[
https://issues.apache.org/jira/browse/HDFS-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056098#comment-14056098
]
Charles Lamb commented on HDFS-6422:
------------------------------------
[~yi.a.liu], [~umamaheswararao],
Given Uma's work on HDFS-6556, I want to clarify what remains to be done on
this patch. Earlier in the comments, I said:
{quote}
Throw an exception if:
. the caller requests an attribute that doesn't exist,
. the caller requests an attribute and they don't have proper permissions,
. the caller requests an attribute and they don't have permission to the
namespace. This applies to the trusted namespace.
. the caller specifies an unknown namespace.
The gist of Linux extended attribute permissions is that you need access to the
inode to read/write xattr names and you need access to the entity itself (i.e.
a file or directory) to read/write xattr values. The former is determined by
the parent directory permissions and the latter by the entity's permissions
(i.e. the thing on which the extended attributes are associated).
You need scan/execute permissions on the parent (owning) directory to access
extended attribute names. You need read permission on the entity itself to read
extended attribute values and you need write permission to modify them.
{quote}
Do you believe you have the permissions checking correct now and that only the
exception throwing needs to be fixed or is there still more work to be done on
read permissions? Specifically, 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?
> 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)
