hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5899) Add configuration flag to disable/enable support for ACLs.
Date Mon, 10 Feb 2014 19:02:19 GMT

    [ 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

View raw message