hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-4317) Job view ACL checks are too permissive
Date Mon, 25 Jun 2012 23:25:43 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401015#comment-13401015
] 

Karthik Kambatla commented on MAPREDUCE-4317:
---------------------------------------------

Let me explain in more detail:

JSPUtil.checkAccessAndGetJob() takes HTTPServletRequest as input. HTTPServletRequest.getRemoteUser()
returns null if the user is not authenticated. For this case, check for user == null should
suffice.

However, I have noticed while testing (TestWebUIAuthorization.validateTaskGraphServletAccess()
in the patch) that when we build the HTTPServletRequest with user == null, the corresponding
url captures the user as "null". For such cases, where the client mistakenly captures the
user as "null", we need to check user.equals("null") as well. 

Do you think we should change the way client builds the HTTPServletRequest?

Many thanks.
                
> Job view ACL checks are too permissive
> --------------------------------------
>
>                 Key: MAPREDUCE-4317
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-4317
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv1
>    Affects Versions: 1.0.3
>            Reporter: Harsh J
>            Assignee: Karthik Kambatla
>         Attachments: MR-4317.patch
>
>
> The class that does view-based checks, JSPUtil.JobWithViewAccessCheck, has the following
internal member:
> {code}private boolean isViewAllowed = true;{code}
> Note that its true.
> Now, in the method that sets proper view-allowed rights, has:
> {code}
> if (user != null && job != null && jt.areACLsEnabled()) {
>       final UserGroupInformation ugi =
>         UserGroupInformation.createRemoteUser(user);
>       try {
>         ugi.doAs(new PrivilegedExceptionAction<Void>() {
>           public Void run() throws IOException, ServletException {
>             // checks job view permission
>             jt.getACLsManager().checkAccess(job, ugi,
>                 Operation.VIEW_JOB_DETAILS);
>             return null;
>           }
>         });
>       } catch (AccessControlException e) {
>         String errMsg = "User " + ugi.getShortUserName() +
>             " failed to view " + jobid + "!<br><br>" + e.getMessage() +
>             "<hr><a href=\"jobtracker.jsp\">Go back to JobTracker</a><br>";
>         JSPUtil.setErrorAndForward(errMsg, request, response);
>         myJob.setViewAccess(false);
>       } catch (InterruptedException e) {
>         String errMsg = " Interrupted while trying to access " + jobid +
>         "<hr><a href=\"jobtracker.jsp\">Go back to JobTracker</a><br>";
>         JSPUtil.setErrorAndForward(errMsg, request, response);
>         myJob.setViewAccess(false);
>       }
>     }
>     return myJob;
> {code}
> In the above snippet, you can notice that if user==null, which can happen if user is
not http-authenticated (as its got via request.getRemoteUser()), can lead to the view being
visible since the default is true and we didn't toggle the view to false for user == null
case.
> Ideally the default of the view job ACL must be false, or we need an else clause that
sets the view rights to false in case of a failure to find the user ID.

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

        

Mime
View raw message