[
https://issues.apache.org/jira/browse/HADOOP-11321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232176#comment-14232176
]
Chris Nauroth commented on HADOOP-11321:
----------------------------------------
bq. This seems like a bug in FileSystem-- can you open a follow-on JIRA?
I filed HADOOP-11347. I agree that it needs to be targeted to 3.0, because
applications might depend on the current behavior.
bq. This still seems like incorrect behavior to me. If someone asks us for a
restrictive set of permissions and we create the file with a more relaxed set,
that seems insecure.
I just had an a-ha moment reading the man page for CIFS mounts:
http://linux.die.net/man/8/mount.cifs
{quote}
File And Directory Ownership And Permissions
The core CIFS protocol does not provide unix ownership information or mode for
files and directories. Because of this, files and directories will generally
appear to be owned by whatever values the uid= or gid= options are set, and
will have permissions set to the default file_mode and dir_mode for the mount.
Attempting to change these values via chmod/chown will return success but have
no effect.
{quote}
This explains the behaviors I've seen in Cygwin and SMB shares mounted on Linux
clients. While this can be seen as a security hole, it's a known issue in the
CIFS protocol, and we're not going to be able to do anything to change that.
bq. I think maybe the right thing to do is to issue a LOG.info if the process
umask doesn't match the configured value of fs.permissions.umask-mode. Most
users are probably running with a umask that matches fs.permissions.umask-mode
anyway. If they aren't, the only problem is that the LocalFilesystem will
create files with more restrictive permissions than intended. This isn't a
security hole, just a hassle, since things are just more locked down than
intended. And it should be easy to fix if the user reads the logs and realizes
his umask is wrong.
I suppose we can do this, but there is a risk that it would be
backwards-incompatible. I think this is something else that can't be done on
the 2.x line and would have to wait for 3.0. We can't anticipate if there are
applications running with a 027 process umask and relying on the alternative
contract of {{FileSystem}} to open up read access for other on new files.
After deploying the change in those environments, others would no longer be
able to access new files. As you said, this one is not a security problem, but
it is a functionality problem. Users would have to respond by either adding
explicit {{chmod}} calls or relaxing their process umask (and possibly
compromising security concerns in other parts of their code).
Regarding the info logging, we might just have to skip it, or at least suppress
it when used from the fs shell. No one wants log output when running the shell
commands.
bq. If you want to just do the Windows part here, I am +1 on that. But I think
we should also do this for Linux. We should eliminate this race condition on
all platforms. So if you choose to just do Windows here, I'll open a follow-on
JIRA for Linux.
Thanks, Colin. My focus is here is just getting functionality working on 2.x
for both Linux and Windows. This is going to restore functionality that had
been working in 1.x. My current assessment is that the patch will impact
Windows code only. I'm not focused on the atomicity problem in the current
code. Please feel free to file a follow-up, but again, I believe it must
target 3.0.
> 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,
> winutils.tmp.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)
