[
https://issues.apache.org/jira/browse/HDFS-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863519#comment-13863519
]
Chris Nauroth commented on HDFS-5673:
-------------------------------------
bq. I wonder whether userEntry will be assigned twice. Maybe I miss something,
I'm unaware of the corresponding checks.
Scope + type + name is unique. The only way that assignment could execute
twice is if a user tried to supply multiple access owner entries in the ACL
spec. If that happens, then the whole request would get rejected anyway by the
duplicate entry check in {{AclTransformation#buildAndValidateAcl}}.
bq. ...there are a couple disadvantages of always using ACLs for FsPermission...
To clarify, we will not always translate FsPermission to List<AclEntry>,
especially not at enforcement time. That was never the intention. If you look
at my HDFS-5612 patch, you'll see that enforcement retains exactly the existing
code path for checking permissions against an {{FsPermission}}. A separate
code path is called only if the ACL feature is defined on the inode. In the
case of a namespace that never uses ACLs, the ACL enforcement code path will
never run.
The conversion I discussed above is only required during execution of
{{FSNamesystem#setPermission}}, and only if the target inode already has an
ACL. (Once again, this is consistent with the design approach that namespaces
that don't use ACLs don't pay a resource cost for the feature.) It's going to
involve creating a small temporary list of 3 ACL entries and then calling the
merge function. This happens while holding the write lock, so there aren't
going to be multiple concurrent RPC threads allocating more objects. There is
no serialization cost, because it's a temporary variable that doesn't transit
the RPC interface.
bq. Based on my understanding, Linux separates the logic of ACLs and
FsPermission, and it has a special bit to indicate whether ACLs are enabled.
This is correct, and our implementation plan for HDFS is in agreement with it.
The only thing I'd add is that when a user runs chmod on an inode that already
has an ACL, then special handling is required, hence the translation to a
minimal ACL and running the merge function. chmod can change the group
permissions, and since group permissions contribute to the ACL's mask entry, we
need to recalculate the mask during chmod calls.
> Implement logic for modification of ACLs.
> -----------------------------------------
>
> Key: HDFS-5673
> URL: https://issues.apache.org/jira/browse/HDFS-5673
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: HDFS ACLs (HDFS-4685)
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-5673.1.patch, HDFS-5673.2.patch, HDFS-5673.3.patch,
> HDFS-5673.4.patch
>
>
> This patch will include the core logic for modification of ACLs. This
> includes support for all user-facing APIs that modify ACLs. This will cover
> access ACLs, default ACLs, automatic mask calculations, automatic inference
> of unprovided default ACL entries, and validation to prevent creation of an
> invalid ACL.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
