[
https://issues.apache.org/jira/browse/HADOOP-11321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226818#comment-14226818
]
Colin Patrick McCabe commented on HADOOP-11321:
-----------------------------------------------
I guess my concern is that if the user requests a restrictive permission on the
newly created file, and the system denies it, sets a more permissive one
instead, and returns no error... that would be considered a security hole. I
could imagine malicious users playing games with moving newly created files
around rapidly so that some user got an EACESS, and silently failed to set the
permission the file they created. After all, it's possible for a user to have
write permission on a directory, without having read permission on any of the
files inside of it. And this gives the bad guy the ability to move around
files as he likes.
To be honest, I really don't like the way we do this right now, even
independently of your patch. Creating the file and setting the permissions on
the file should not be two separate steps. The way we do it now opens us up to
race conditions and possibly worse. And of course, it's less efficient to do
two syscalls rather than one.
There is a {{FileInputStream}} constructor that takes a {{FileDescriptor}}.
This might allow us to do the "open" and "set permissions" steps as a single
atomic step. I'm not familiar with the APIs on Windows, but certainly on
Linux, the {{creat}} syscall takes an argument that can set the permissions of
what it is creating. Is there a native API on Windows that creates a file with
certain permissions? Even if {{Files#createFile}} doesn't work on Windows, we
must have some JNI function we can write that does? This would fix the race
condition and eliminate the problem you're describing here, at one go. Sure,
we might have to use different methods of getting the {{FileDsecriptor}} on
Linux and Windows, but that seems OK.
cygwin is an interesting precedent, but have you confirmed that it is doing the
same thing as we are (creating the file and setting permissions in two separate
steps?) I would be surprised if it was. It's ok to create the file or
directory with more restrictive permissions than what was requested, but
silently opening up the permissions is not ok, I think.
> copyToLocal cannot save a file to an SMB share unless the user has Full
> Control permissions.
> --------------------------------------------------------------------------------------------
>
> Key: HADOOP-11321
> URL: https://issues.apache.org/jira/browse/HADOOP-11321
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 2.6.0
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HADOOP-11321.1.patch, HADOOP-11321.2.patch
>
>
> In Hadoop 2, it is impossible to use {{copyToLocal}} to copy a file from HDFS
> to a destination on an SMB share. This is because in Hadoop 2, the
> {{copyToLocal}} maps to 2 underlying {{RawLocalFileSystem}} operations:
> {{create}} and {{setPermission}}. On an SMB share, the user may be
> authorized for the {{create}} but denied for the {{setPermission}}. Windows
> denies the {{WRITE_DAC}} right required by {{setPermission}} unless the user
> has Full Control permissions. Granting Full Control isn't feasible for most
> deployments, because it's insecure. This is a regression from Hadoop 1,
> where {{copyToLocal}} only did a {{create}} and didn't do a separate
> {{setPermission}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
