[
https://issues.apache.org/jira/browse/HADOOP-13612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490877#comment-15490877
]
Chris Nauroth commented on HADOOP-13612:
----------------------------------------
Steve, thank you for the patch. I hear where you're coming from, but
unfortunately, -1 on grounds of backward compatibility.
The key point is this statement from the JavaDocs of the static {{mkdirs}}:
{code}
* The permission of the directory is set to be the provided permission as in
* setPermission, not permission&~umask
{code}
This is what sets apart static mkdirs from member mkdirs. If you look at, for
example, {{DistributedFileSystem}}/{{DFSClient}}, the member mkdirs always
applies umask on top of the passed {{FsPermission}} argument. The semantics of
static mkdirs is that it ignores umask.
The weaknesses of the static mkdirs (multiple RPCs/lack of atomicity) are
unfortunate, but we can't solve it by forwarding to member mkdirs. We'd
probably need to make a more complicated change, like providing a new specific
"mkdirs-ignore-umask" member method with this default inefficient
implementation, and optionally changing subclasses to override it for better
performance and atomicity, or perhaps reviewing application call sites to see
if they can somehow implement their requirements with the existing member
mkdirs. (Maybe they could set umask to 000 and completely take over their
permission logic?)
BTW, the same argument applies to the static {{FileSystem#create}}.
> FileSystem static mkdirs(FS, path, permissions) to invoke FS.mkdirs(path,
> permissions)
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-13612
> URL: https://issues.apache.org/jira/browse/HADOOP-13612
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 2.7.3
> Reporter: Steve Loughran
> Attachments: HADOOP-13612-branch-2-001.patch
>
>
> Currently {{FileSystem}}'s static {{mkdirs(FileSystem fs, Path dir,
> FsPermission permission)}} creates the directory in a two step operation
> {code}
> // create the directory using the default permission
> boolean result = fs.mkdirs(dir);
> // set its permission to be the supplied one
> fs.setPermission(dir, permission);
> {code}
> this isn't atomic and creates a risk of race/security conditions. *This code
> is used in production*
> Better to simply forward to mkdirs(path, permissions).
> is there any reason to not do that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
