[
https://issues.apache.org/jira/browse/HDFS-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908481#comment-16908481
]
Eric Yang commented on HDFS-2470:
---------------------------------
[~swagle] Thank you for patch 07. I think the right fix is not setting root
directory permission. HDFS is smart about creating subdirectory from root
directory. The root directory is a system admin defined location or the
provision system should initialize the directory properly with proper ownership
and permission. Without setting root directory permission, the solution is
more generic that works for both /tmp or /tmp/namenode.
Would it be safer to pass in a default permission of 0700 instead of null for
the constructors that did not accept permission parameter? In the past, the
files and directories are created based on user umask. This cause all files to
be readable by anyone on standard Linux installation. For HDFS, ihdfs user
would want to keep all data private, unless explicitly required by very old
version of short circuit read. Hence, it might be useful to pass default
permission and we can skip the null check to ensure data are secured by default
unless explicitly allowed.
> NN should automatically set permissions on dfs.namenode.*.dir
> -------------------------------------------------------------
>
> Key: HDFS-2470
> URL: https://issues.apache.org/jira/browse/HDFS-2470
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.0-alpha
> Reporter: Aaron T. Myers
> Assignee: Siddharth Wagle
> Priority: Major
> Attachments: HDFS-2470.01.patch, HDFS-2470.02.patch,
> HDFS-2470.03.patch, HDFS-2470.04.patch, HDFS-2470.05.patch,
> HDFS-2470.06.patch, HDFS-2470.07.patch
>
>
> Much as the DN currently sets the correct permissions for the
> dfs.datanode.data.dir, the NN should do the same for the
> dfs.namenode.(name|edit).dir.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
