[
https://issues.apache.org/jira/browse/HDFS-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896858#comment-13896858
]
Chris Nauroth commented on HDFS-5899:
-------------------------------------
bq. I agree that we should never wipe ACLs automatically. But what's the
problem with just not enforcing them when dfs.namenode.acls.enabled is false?
Why do we have to fail to start up? That seems like it will introduce problems
for admins.
If ACLs were defined, but not enforced, then the cluster would be in a state of
partial enforcement. The traditional permission bits would be enforced, but
the ACLs would be ignored during permission checks. In all respects, it would
appear to end users that they have set an ACL correctly on their file, but they
wouldn't know that the rules aren't really being enforced. This could open a
risk of unauthorized access. It's particularly dangerous when we consider that
for an inode with an ACL, the group permission bits store the mask, not the
group permissions. The default setting of the mask is calculated as the union
of permissions for all named user entries, named group entries, and the unnamed
group entry in the ACL. This union may be wider than the permissions intended
for the file's group.
The combination of {{dfs.permissions.enabled=false}} +
{{dfs.namenode.acls.enabled=true}} would work for deployments that want to
allow setting of ACLs but skip enforcement (and also skip enforcement of
permission bits).
The motivation for this patch was to provide a "feature flag". (Sorry to bring
that phrase up again and risk confusion with HDFS-5223, but it's the best
description.) An admin can leave this toggled off and be guaranteed that the
feature is completely off, including no consumption of RAM or disk by ACLs.
Note that in order to reach this state, the admin must have toggled ACL support
on in configuration at some point. It's off by default, so turning it on was a
conscious decision. Then, the admin has a change of heart and decides to turn
ACLs off, but meanwhile, a user snuck in with a setfacl. I expect this to be a
rare situation.
bq. How do you propose that the admin do this?
Our existing tools have it covered. Startup with ACLs enabled. Remove ACLs
using setfacl -x. There is a recursive option if it's necessary to remove from
a whole sub-tree. Enter safe mode. Save a new checkpoint. Restart with ACLs
disabled.
> Add configuration flag to disable/enable support for ACLs.
> ----------------------------------------------------------
>
> Key: HDFS-5899
> URL: https://issues.apache.org/jira/browse/HDFS-5899
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: HDFS ACLs (HDFS-4685)
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Fix For: HDFS ACLs (HDFS-4685)
>
> Attachments: HDFS-5899.1.patch, HDFS-5899.2.patch
>
>
> Add a new configuration property that allows administrators to toggle support
> for HDFS ACLs on/off. By default, the flag will be off. This is a
> conservative choice, and administrators interested in using ACLs can enable
> it explicitly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
