[ 
https://issues.apache.org/jira/browse/HADOOP-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702320#action_12702320
 ] 

Amar Kamat commented on HADOOP-5737:
------------------------------------

bq. Does this anomaly happen in all test-cases? Or only in 
TestMiniMRWithDFSWithDistinctUsers? 
This happens whenever the users for jobtracker and job are different. For 
example, the jobtracker runs as _foo_ and a user _bar_ submits a job. So what 
happens in these testcase is that
# user bar submits a job
# jobtracker (running as foo) tries to do a job.init()
# fs does read-permission check and uses {{ugi = 
UserGroupInformation.getCurrentUGI()}} which points to user bar. 

Ideally the ugi should point to jobtracker's user. 

bq. Also, another thing to check is whether it happens only in when using the 
Mini* clusters, and not in single-node cluster etc. 
Arun this is a bug with the testcase only. I will still try it out on a single 
node cluster.

> UGI checks in testcases are broken
> ----------------------------------
>
>                 Key: HADOOP-5737
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5737
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: test
>            Reporter: Amar Kamat
>
> While running {{TestMiniMRWithDFSWithDistinctUsers}}, I used this patch to 
> test the ugi checks 
> {code}
> Index: src/hdfs/org/apache/hadoop/hdfs/server/namenode/PermissionChecker.java
> ===================================================================
> --- src/hdfs/org/apache/hadoop/hdfs/server/namenode/PermissionChecker.java    
> (revision 768189)
> +++ src/hdfs/org/apache/hadoop/hdfs/server/namenode/PermissionChecker.java    
> (working copy)
> @@ -40,6 +40,7 @@
>      if (LOG.isDebugEnabled()) {
>        LOG.debug("ugi=" + ugi);
>      }
> +    LOG.info("ugi=" + ugi);
>  
>      if (ugi != null) {
>        user = ugi.getUserName();
> {code}
> While initializing a job, the ugi information should point to jobtracker as 
> jobtracker does a dfs read. But today we will see that the log shows _pi_ as 
> the caller instead of the jobtracker.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to