[
https://issues.apache.org/jira/browse/HDFS-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-5899:
--------------------------------
Summary: Add configuration flag to disable/enable support for ACLs. (was:
Add feature flag in configuration to disable/enable support for ACLs.)
bq. I recommend not calling this a "feature flag" since that seems to invite
confusion with HDFS-5223.
That sounds good. I updated the issue summary. There isn't anything in the
code I've written so far that actually uses the name "feature flag", so no
changes required there.
This new property is going to be more like what we did in branch-2.2 to block
symlinks. It will control whether or not ACLs can exist in the namespace at
all. For cluster admins who prefer to stick with the simplicity of permission
bits, or who simply don't want to start using a new feature in its first
release, they can leave it off. When ACLs are disabled, all APIs related to
ACLs will fail intentionally, an fsimage containing an ACL will cause the
NameNode to abort during startup, and ACLs present in the edit log will cause
the NameNode to abort. If ACLs accidentally crept into the fsimage or edits
(i.e. accidentally started with ACLs enabled, but now the admin wants to switch
them off), then the recovery procedure would be to restart with ACLs enabled,
remove all ACLs, save a new checkpoint, and then restart with ACLs disabled.
Existing ACLs never get wiped automatically. This recovery procedure is a
conscious decision by the cluster admin.
A potential gotcha here is enabling ACLs on one NameNode but not the other in
an HA pair. The standby would fail to apply edits containing ACLs. Keeping
configs in sync between active and standby is already important for a lot of
other reasons though, so this shouldn't be any more cumbersome.
A few more points about how ACLs interact with existing permissions logic
(unrelated to this patch):
* {{dfs.permissions.enabled}} continues to work as expected, suppressing
permission checks if set to false, whether the permissions are defined via
permission bits or ACLs.
* The superuser is still immune to all permission checks, whether they come
from permission bits or ACLs.
* If ACLs are not in use, then permission checks go through the exact same code
path that we have in {{FSPermissionChecker}} today. We go down a separate path
only if the inode has an ACL.
> 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
>
> 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)
