[
https://issues.apache.org/jira/browse/HADOOP-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686247#comment-13686247
]
Chuan Liu commented on HADOOP-9637:
-----------------------------------
Thanks for reviewing, Chris!
>If I understand correctly, this is intended to remove the domain portion from
>a username. (Am I understanding it correctly?) Does Windows ever prepend
>domain to the group name too? Do we need similar logic for initializing
>this.group?
You are right. We also need this for group name. I will fix this in a new patch.
>It seems that this logic would treat user DOMAIN1\cnauroth the same as
>DOMAIN2\cnauroth, when in reality the same username in 2 different domains
>might not be the same person. Consumers of fstat would end up seeing
>"cnauroth" as the owner without being able to differentiate between the 2
>different users in 2 different domains. Is this acceptable?
This is by design right now. UserGroupInformation, NativeIO.Windows.getOwner(),
and a few other places all assume this pattern, i.e. username without domain.
(UserGroupInformation does not explicitly strip the domain, however, the Java
API it used only returns username.) There are some discussions on this in
HADOOP-8455. The main scenario we want to support (for unsecure Hadoop on
Windows) is to allow local users of the same name to run Hadoop cluster without
a domain controller. For example, users can create local user 'Alex' on the two
machines 'Win1' and 'Win2', and run Hadoop under the local user 'Alex'. I think
it is acceptable for now; I have outlined some thoughts on how we can improve
this in HADOOP-8455.
>Minor nit: use 2-space indentation in the above code.
Thanks for pointing this out; will fix in new patch.
>Does this mean that we need to subtract 1 from cchPathLen earlier, such as
>when we assign cchPathLen = dwRtnCode?
Not necessary. I have similar thoughts when I wrote the code. I intentionally
make the buffer size 1 char larger; so the last character is the NULL
terminator. Because without NULL terminator, some functions, e.g. wcslen(),
will fail on the string, including some Windows function like
GetNamedSecurityInfo() that is called on the path later. I think the MSDN
document means the buffer only need to be as large as string length without
null terminator. However, it does not require the buffer to be exact size. You
may notice the example given at the MSDN page also used a larger buffer to save
the path.
> Adding Native Fstat for Windows as needed by YARN
> -------------------------------------------------
>
> Key: HADOOP-9637
> URL: https://issues.apache.org/jira/browse/HADOOP-9637
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.0.0, 2.1.0-beta
> Reporter: Chuan Liu
> Assignee: Chuan Liu
> Attachments: HADOOP-9637-trunk.patch
>
>
> TestAggregatedLogFormat.testContainerLogsFileAccess test case fails on
> Windows. The test case try to simulate a situation where first log file is
> owned by different user (probably symlink) and second one by the user itself.
> In this situation, the attempt to try to aggregate the logs should fail with
> the error message "Owner ... for path ... did not match expected owner ...".
> The check on file owner happens at {{AggregatedLogFormat.write()}} method.
> The method calls {{SecureIOUtils.openForRead()}} to read the log files before
> writing out to the OutputStream.
> {{SecureIOUtils.openForRead()}} use {{NativeIO.Posix.getFstat()}} to get the
> file owner and group. We don't have {{NativeIO.Posix.getFstat()}}
> implementation on Windows; thus, the failure.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
