[
https://issues.apache.org/jira/browse/HDFS-10488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15317387#comment-15317387
]
Chris Nauroth commented on HDFS-10488:
--------------------------------------
-1 for the proposed change.
The umask ({{fs.permissions.umask-mode}}) is a concept that is applied at the
client side by individual applications, usually via their usage of the
FileSystem subclasses that implement a particular file system client. The
umask is not applied by the API/protocol layer such as WebHDFS or NameNode RPC.
As such, the behavior of the shell, which applies umask, is not always going
to look consistent with the behavior of a direct curl WebHDFS call, which does
not apply the umask.
Using the shell to access WebHDFS gives consistent results, because the logic
of the WebHdfsFileSystem class used by the shell will apply the umask.
If this patch were committed, then it would become basically impossible to
create files and directories with absolute permissions through WebHDFS. For
example, suppose {{fs.permissions.umask-mode}} is set to 022, but an individual
application has a desire to create a file with 775 permissions. This wouldn't
work as expected, because server-side enforcement of the umask would restrict
permissions on the resulting file to 755. The only way to work around this
would be to reconfigure {{fs.permissions.umask-mode}} and restart the NameNode,
which isn't operationally desirable. Worse than that, this would likely have
the long-term effect of reducing {{fs.permissions.umask-mode}} to lowest common
denominator, perhaps even 000, to accommodate all possible permissions at file
creation time, thus weakening the benefit of umask as applied by client
applications like the shell.
As a final point against this change, please note that it could be considered
backwards-incompatible. In my example above trying to create a file with 775
permissions, but the server-side umask forcing it to 755, it means that
subsequent write actions by users in the same group will be unauthorized. This
may break certain workflows.
The area where there is a possibility for change is documentation to help raise
user awareness of this. That could potentially go into the HDFS Permissions
Guide page or the WebHDFS REST API page, or perhaps some combination of both.
I would be happy to help review and +1 documentation changes.
[~wchevreuil], despite my -1, thank you for writing up your experience with
this and posting a patch. If you'd like to proceed with a documentation patch,
please let me know, and I'll assign the issue to you.
> WebHDFS CREATE and MKDIRS does not follow same rules as DFS CLI when creating
> files/directories without specifying permissions
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-10488
> URL: https://issues.apache.org/jira/browse/HDFS-10488
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 2.6.0
> Reporter: Wellington Chevreuil
> Priority: Minor
> Attachments: HDFS-10488.002.patch, HDFS-10488.003.patch,
> HDFS-10488.patch
>
>
> WebHDFS methods for creating file/directories are always creating it with 755
> permissions as default, even ignoring any configured
> *fs.permissions.umask-mode* in the case of directories.
> Dfs CLI, however, applies the configured umask to 777 permission for
> directories, or 666 permission for files.
> Example below shows the different behaviour when creating directory via CLI
> and WebHDFS:
> {noformat}
> 1) Creating a directory under '/test/' as 'test-user'. Configured
> fs.permissions.umask-mode is 000:
> $ sudo -u test-user hdfs dfs -mkdir /test/test-user1
> $ sudo -u test-user hdfs dfs -getfacl /test/test-user1
> # file: /test/test-user1
> # owner: test-user
> # group: supergroup
> user::rwx
> group::rwx
> other::rwx
> 4) Doing the same via WebHDFS does not get the proper ACLs:
> $ curl -i -X PUT
> "http://namenode-host:50070/webhdfs/v1/test/test-user2?user.name=test-user&op=MKDIRS";
>
> $ sudo -u test-user hdfs dfs -getfacl /test/test-user2
> # file: /test/test-user2
> # owner: test-user
> # group: supergroup
> user::rwx
> group::r-x
> other::r-x
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
