hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10213) setfacl -x should reject attempts to include permissions in the ACL spec.
Date Wed, 15 Jan 2014 00:49:21 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871437#comment-13871437
] 

Chris Nauroth commented on HADOOP-10213:
----------------------------------------

bq. In general, there will be only one ACL entry per user/group in each type no matter what
are the permissions. I agree that we cannot consider "user:bruce:rwx" and "user:bruce:---"
as equal, but also both these entries cannot be present in list of ACL entries right?

This is correct.  It doesn't make sense to have 2 different ACL entries with the same scope
+ type + name.  We already enforce this on the NameNode side in {{AclTransformation#buildAndValidateAcl}}.
 The validation logic rejects duplicate ACL entries, where two entries are considered duplicate
if they have the same scope + type + name (even if the permissions are different).  If a user
supplies duplicates like this, then we'll return an error.  This is regardless of whether
the request comes in through the CLI, another interface, or programmatically through {{FileSystem}}
method calls.  The enforcement is centralized on the server side.

bq. So my preference is that we need to check for permissions separately whenever necessary,
instead of including in equals() and hashCode().

Considering that the NameNode is enforcing the required uniqueness on the server side, let's
not remove permissions from consideration in {{equals}} and {{hashCode}}.  There are 2 reasons
for this:

# As mentioned above, it's a public user-facing class, and most callers will have an intuition
that {{equals}} and {{hashCode}} consider all data members.
# I'm also anticipating that we'll want to include perms when the NameNode starts de-duplicating
ACLs via the Global ACL Set as described in the design doc (HDFS-5620).  The implementation
of this is likely to be sensitive to {{equals}} and {{hashCode}}, and we wouldn't want it
to de-duplicate "user:bruce:---" based on seeing that "user:bruce:rwx" already exists in the
live set.  If we remove perms from the {{AclEntry}} implementation here, then the NameNode
is likely going to have to translate everything to some kind of alternative internal class
with an {{equals}} and {{hashCode}} that includes perms.  This would require additional awkward
data copying code.

> setfacl -x should reject attempts to include permissions in the ACL spec.
> -------------------------------------------------------------------------
>
>                 Key: HADOOP-10213
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10213
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: tools
>    Affects Versions: HDFS ACLs (HDFS-4685)
>            Reporter: Chris Nauroth
>            Assignee: Vinay
>         Attachments: HADOOP-10213.patch
>
>
> When calling setfacl -x to remove ACL entries, it does not make sense for the entries
in the ACL spec to contain permissions.  The permissions should be unspecified, and the CLI
should return an error if the user attempts to provide permissions.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message