[
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)
