[
https://issues.apache.org/jira/browse/HDFS-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-6962:
--------------------------------
Target Version/s: 3.0.0 (was: 2.7.0)
Hello, [~usrikanth]. Thank you for posting a prototype patch and providing a
great written summary.
I'm now certain that it's impossible to make this change in a
backwards-compatible way in the 2.x line. The biggest challenge is what
happens if someone upgrades the client ahead of the NameNode. In that case,
neither the client nor the NameNode would apply the umask. Effectively, that
means the upgraded client would start creating directories with 777 and files
with 666, which of course would compromise security.
Another potential issue is that existing users may be accustomed to the
behavior of the current implementation, despite this deviation from the POSIX
ACL spec. The effect of the proposed change would be to widen access, because
it would stop applying umask in certain cases. Users might find it surprising
if their default ACLs stopped restricting access after an upgrade, and some
would argue that this is a form of incompatibility with existing persistent
data (metadata). This is always a fine line, but I do suspect some would see
it as an incompatibility.
I'm retargeting this to 3.0.0. That means we'll also have the option of
creating a much simpler patch, because we'll have freedom to make
backwards-incompatible changes.
Here are a few notes on the prototype patch, although I suspect it will go in a
very different direction for 3.0.0 anyway.
# {{CommandWithDestination}}: This change also probably would have constituted
a backwards incompatibility. Prior versions create files as 666 filtered by
{{fs.permissions.umask-mode}}, not based on the permissions from the source
file system. I see from your notes that you were aiming to replicate the
behavior you saw on Linux. It might be worthwhile for us to consider doing
that for consistency with other file systems, but it would be
backwards-incompatible in 2.x.
# {{FSDirectory}}: Here, the NameNode is applying umask based on its configured
value for {{fs.permissions.umask-mode}}. Unfortunately, this won't work in the
general case, because it's not guaranteed that the client and the NameNode are
running with the same set of configuration files. They might have different
values configured for {{fs.permissions.umask-mode}}, or the client might have
overridden it with a -D option on the command line.
> ACLs inheritance conflict with umaskmode
> ----------------------------------------
>
> Key: HDFS-6962
> URL: https://issues.apache.org/jira/browse/HDFS-6962
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 2.4.1
> Environment: CentOS release 6.5 (Final)
> Reporter: LINTE
> Assignee: Srikanth Upputuri
> Labels: hadoop, security
> Attachments: HDFS-6962.1.patch
>
>
> In hdfs-site.xml
> <property>
> <name>dfs.umaskmode</name>
> <value>027</value>
> </property>
> 1/ Create a directory as superuser
> bash# hdfs dfs -mkdir /tmp/ACLS
> 2/ set default ACLs on this directory rwx access for group readwrite and user
> toto
> bash# hdfs dfs -setfacl -m default:group:readwrite:rwx /tmp/ACLS
> bash# hdfs dfs -setfacl -m default:user:toto:rwx /tmp/ACLS
> 3/ check ACLs /tmp/ACLS/
> bash# hdfs dfs -getfacl /tmp/ACLS/
> # file: /tmp/ACLS
> # owner: hdfs
> # group: hadoop
> user::rwx
> group::r-x
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> user::rwx | group::r-x | other::--- matches with the umaskmode defined in
> hdfs-site.xml, everything ok !
> default:group:readwrite:rwx allow readwrite group with rwx access for
> inhéritance.
> default:user:toto:rwx allow toto user with rwx access for inhéritance.
> default:mask::rwx inhéritance mask is rwx, so no mask
> 4/ Create a subdir to test inheritance of ACL
> bash# hdfs dfs -mkdir /tmp/ACLS/hdfs
> 5/ check ACLs /tmp/ACLS/hdfs
> bash# hdfs dfs -getfacl /tmp/ACLS/hdfs
> # file: /tmp/ACLS/hdfs
> # owner: hdfs
> # group: hadoop
> user::rwx
> user:toto:rwx #effective:r-x
> group::r-x
> group:readwrite:rwx #effective:r-x
> mask::r-x
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> Here we can see that the readwrite group has rwx ACL bu only r-x is effective
> because the mask is r-x (mask::r-x) in spite of default mask for inheritance
> is set to default:mask::rwx on /tmp/ACLS/
> 6/ Modifiy hdfs-site.xml et restart namenode
> <property>
> <name>dfs.umaskmode</name>
> <value>010</value>
> </property>
> 7/ Create a subdir to test inheritance of ACL with new parameter umaskmode
> bash# hdfs dfs -mkdir /tmp/ACLS/hdfs2
> 8/ Check ACL on /tmp/ACLS/hdfs2
> bash# hdfs dfs -getfacl /tmp/ACLS/hdfs2
> # file: /tmp/ACLS/hdfs2
> # owner: hdfs
> # group: hadoop
> user::rwx
> user:toto:rwx #effective:rw-
> group::r-x #effective:r--
> group:readwrite:rwx #effective:rw-
> mask::rw-
> other::---
> default:user::rwx
> default:user:toto:rwx
> default:group::r-x
> default:group:readwrite:rwx
> default:mask::rwx
> default:other::---
> So HDFS masks the ACL value (user, group and other -- exepted the POSIX
> owner -- ) with the group mask of dfs.umaskmode properties when creating
> directory with inherited ACL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
