[
https://issues.apache.org/jira/browse/HDFS-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863478#comment-13863478
]
Haohui Mai commented on HDFS-5673:
----------------------------------
for {{promoteDefaultEntries}} and {{calculateMask}}, what I'm essentially
saying is that you can take the advantage of the fact that the ACL list has an
order to simplify the code, rather than scanning through the list.
bq. is this to reduce the footprint of code shipped client side, particularly
code that is sensitive to server side implementation details?
Yes.
bq. because ACCESS is a scope, and the types are USER, GROUP, MASK and OTHER..
I'm talking about the following code:
{code}
for (AclEntry entry: aclBuilder) {
if (entry.getScope() == AclEntryScope.ACCESS) {
if (entry.getType() == AclEntryType.USER && entry.getName() == null) {
userEntry = entry;
}
...
}
{code}
I wonder whether userEntry will be assigned twice. Maybe I miss something, I'm
unaware of the corresponding checks.
bq. If calling setPermission on an inode with an ACL, then it will convert the
client-supplied FsPermission to a minimal ACL (containing exactly the 3 base
entries) ...
I'm wondering whether this is the right way to approach it. Although it can
simplify the enforcement of the permission, there are a couple disadvantages of
always using ACLs for FsPermission, including (1) increaseing the memory
footprint and serialization costs, (2) calling removeAcl() might incidentally
remove the FsPermission.
Based on my understanding, Linux separates the logic of ACLs and FsPermission,
and it has a special bit to indicate whether ACLs are enabled. In my opinion
this separates the reasoning between ACLs and FsPermissions. It seems to me
that it is a much simpler approach comparing to merging and optimizing ACLs,
due to various requirements set by the POSIX drafts.
> 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)
