[ 
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)

Reply via email to