[ 
https://issues.apache.org/jira/browse/HADOOP-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Mitic updated HADOOP-6527:
-------------------------------

    Attachment: HADOOP-6527-branch-1-win_UGI_fix(2).patch

Thanks Nicholas, Bikas!

The patch for HADOOP-7389 works fine, so I would like to propose to port it to 
branch-1-win (ported patch attached). Please let me know if I can do something 
to help with the process besides providing the patch.


PS.
bq. I tried to add only the new test in TestUserGroupInformation without other 
changes to branch-1. The new test still passed.
You are right, my bad. The new test would have to be the first in the list, 
otherwise the real user groups are already cleaned up.

                
> UserGroupInformation::createUserForTesting clobbers already defined group 
> mappings
> ----------------------------------------------------------------------------------
>
>                 Key: HADOOP-6527
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6527
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>            Reporter: Jakob Homan
>            Assignee: Ivan Mitic
>         Attachments: HADOOP-6527-branch-1-win_UGI_fix(2).patch, 
> HADOOP-6527-branch-1-win_UGI_fix.patch
>
>
> In UserGroupInformation::createUserForTesting the follow code creates a new 
> groups instance, obliterating any groups that have been previously defined in 
> the static groups field.
> {code}    if (!(groups instanceof TestingGroups)) {
>       groups = new TestingGroups();
>     }
> {code}
> This becomes a problem in tests that start a Mini{DFS,MR}Cluster and then 
> create a testing user.  The user that started the user (generally the real 
> user running the test) immediately has their groups wiped out and is 
> prevented from accessing files/folders/queues they should be able to.  Before 
> the UserGroupInformation.createRemoteUserForTesting, calls to userA.getGroups 
> may return {"a", "b", "c"} and immediately after the new fake user is 
> created, the same call will return an empty array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to