[
https://issues.apache.org/jira/browse/HDFS-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880440#comment-13880440
]
Sanjay Radia commented on HDFS-4685:
------------------------------------
Comment on the the two alternatives for the default ACL proposals in the doc.
Reproducing the text for convenience.
* *Umask-Default-ACL*: The default ACL of the parent is cloned to the ACL of
the child at time of child creation. For new child directories, the default
ACL itself is also cloned, so that the same policy is applied to
sub-directories of sub-directories. Subsequent changes to the parent’s default
ACL will set a different ACL for new children, but will not alter existing
children. This matches POSIX behavior. If the administrator wants to change
policy on the sub-tree later, then this is performed by inserting a new more
restrictive ACL entry at the appropriate sub-tree root (see UC6) and may also
need to run a recursive ACL modification (analogous to chmod -R) since
existing children are not effected by the new ACL.
* *Inherited-Default-ACL*: A child that does not have an ACL of its own
inherits its ACL from the nearest ancestor that has defined a default ACL. A
child node that requires a different ACL can override the default (like the
Umask-Default-ACL). Subsequent changes to the ancestor’s default ACL will cause
all children that do not have an ACL to inherit the new ACL regardless of child
creation time (unlike Umask-Default-ACL). This model, like the ABAC ACLs (use
case UC8), encourages the user to create fewer ACLs (typically on the root of
specific subtrees) while the Posix-compliant Umask-Default-ACL is expected to
results in larger number of ACLs in the system. It would also make a memory
efficient implementation trivial. Note that this model is a deviation from
POSIX behavior.
Consider the following three sub use cases here
4a) OpenUP child for wide access than the default.
4b) Restrict a child for narrower access than the default.
4c) Change the defaultAcl because you made a mistake originally.
Both models support use case 4a and 4b with equal ease. However, with the
Inherited-Default-ACL, it is easy to identify children that have overridden the
default-ACL - the existence of an ACL means that the user intended to override
the default. Also 4c is a natural fit for Inherited-Default-ACL. For the
UMask-Default-ACL, every child has an ACL and hence you have to walk down the
subtree and compare the ACL with the default to see if the user had intended to
override it.
I think the Inherited-Default-ACL is much better design but posix compliance
may triumph and hence am willing to go with UMask-Default-ACL.
> Implementation of ACLs in HDFS
> ------------------------------
>
> Key: HDFS-4685
> URL: https://issues.apache.org/jira/browse/HDFS-4685
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: hdfs-client, namenode, security
> Affects Versions: 1.1.2
> Reporter: Sachin Jose
> Assignee: Chris Nauroth
> Attachments: HDFS-ACLs-Design-1.pdf, HDFS-ACLs-Design-2.pdf
>
>
> Currenly hdfs doesn't support Extended file ACL. In unix extended ACL can be
> achieved using getfacl and setfacl utilities. Is there anybody working on
> this feature ?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
