[
https://issues.apache.org/jira/browse/HADOOP-11321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HADOOP-11321:
-----------------------------------
Attachment: HADOOP-11321.006.patch
Thanks for the code review, Colin. I'm uploading patch v006 with the following
changes.
* {{ChecksumFileSystem}}: Removed the special case for calling
{{setPermission}}. I agree that this shouldn't be necessary anymore.
* {{NativeIO#createDirectoryWithMode}}: Changed to propagate the exception.
* {{RawLocalFileSystem#mkOneDirWithMode}}: Changed to catch the exception and
return {{false}}.
* {{NativeIO.c}}: Changed to use {{#else}} instead of {{#ifdef UNIX}} and
updated error messages.
* {{libwinutils.c}}: I discovered a bug in our logic for deciding to convert to
long path format. Normally, the length restriction is defined by {{MAX_PATH}},
which we already check. However, for directories, there is an additional
requirement that it must be possible to append a child file name in 8.3 format
(12 characters). This is documented about 1/3 of the page down here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
. The patch handles this the same way that the JDK code handles it, by
checking for {{MAX_PATH - 12}}.
* {{TestLocalDirsHandlerService}}: I discovered an odd behavior in
{{FileContext#mkdir}}. You can pass in an {{FsPermission}}. If creation of
the directory fails because it already exists, then we still call
{{setPermission}} and potentially change the mode. This happens due to the
code in the current trunk version of {{RawLocalFileSystem#primitiveMkdir}}.
This seems like a bug. POSIX {{mkdir}} and {{FileSystem}} don't behave this
way. By removing {{RawLocalFileSystem#primitiveMkdir}} in my patch, that
behavior is going away. I found that {{TestLocalDirsHandlerService}} was
depending on this old behavior, but it's probably just a coincidence that the
test suite keeps reusing the same directories across multiple tests. I changed
the test suite to clean up in between tests. If anyone thinks this behavior of
{{FileContext}} is intentional, please let me know.
bq. I guess this is a nitpick, but perhaps we should only set ppSD when the
return code is success?
At this point in the code, it's guaranteed that the return code is success.
The earlier code paths check the individual API calls for errors, and if found,
jump to the {{done}} label, going past the assignment to {{ppSD}}. (I do agree
with the principle that functions should only write to an out parameter if it
succeeds.)
> 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.003.patch, HADOOP-11321.004.patch,
> HADOOP-11321.005.patch, HADOOP-11321.006.patch, 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)
