[
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.007.patch
I'm attaching patch v007. This has one small change from v006, shown in the
incremental diff below. Instead of basing ownership on the TokenUser of the
current process, the new patch uses TokenOwner. According to documentation,
this is the correct way to identify the default owner SID for newly created
objects.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379626%28v=vs.85%29.aspx
More details are here:
http://technet.microsoft.com/en-us/library/cc961992.aspx
With this change, we correctly handle the special case that for files created
by a member of the Administrators group, the ownership is set to the
Administrators group instead of to the individual user SID.
{code}
diff --git
a/hadoop-common-project/hadoop-common/src/main/winutils/libwinutils.c
b/hadoop-common-project/hadoop-c
index c1dd914..040d563 100644
--- a/hadoop-common-project/hadoop-common/src/main/winutils/libwinutils.c
+++ b/hadoop-common-project/hadoop-common/src/main/winutils/libwinutils.c
@@ -1515,7 +1515,7 @@ static DWORD GetWindowsDACLsForCreate(__in INT mode,
__out PACL *ppDACL) {
DWORD dwRtnCode = ERROR_SUCCESS;
HANDLE hToken = NULL;
DWORD dwSize = 0;
- PTOKEN_USER pTokenUser = NULL;
+ PTOKEN_OWNER pTokenOwner = NULL;
PTOKEN_PRIMARY_GROUP pTokenPrimaryGroup = NULL;
PSID pOwnerSid = NULL, pGroupSid = NULL;
PACL pDACL = NULL;
@@ -1525,11 +1525,11 @@ static DWORD GetWindowsDACLsForCreate(__in INT mode,
__out PACL *ppDACL) {
goto done;
}
- dwRtnCode = GetTokenInformationByClass(hToken, TokenUser, &pTokenUser);
+ dwRtnCode = GetTokenInformationByClass(hToken, TokenOwner, &pTokenOwner);
if (dwRtnCode != ERROR_SUCCESS) {
goto done;
}
- pOwnerSid = pTokenUser->User.Sid;
+ pOwnerSid = pTokenOwner->Owner;
dwRtnCode = GetTokenInformationByClass(hToken, TokenPrimaryGroup,
&pTokenPrimaryGroup);
@@ -1549,7 +1549,7 @@ done:
if (hToken) {
CloseHandle(hToken);
}
- LocalFree(pTokenUser);
+ LocalFree(pTokenOwner);
LocalFree(pTokenPrimaryGroup);
return dwRtnCode;
}
{code}
> 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.007.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)