From mapreduce-issues-return-48354-apmail-hadoop-mapreduce-issues-archive=hadoop.apache.org@hadoop.apache.org Mon Jun 25 23:01:45 2012 Return-Path: X-Original-To: apmail-hadoop-mapreduce-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B2363997E for ; Mon, 25 Jun 2012 23:01:45 +0000 (UTC) Received: (qmail 50360 invoked by uid 500); 25 Jun 2012 23:01:45 -0000 Delivered-To: apmail-hadoop-mapreduce-issues-archive@hadoop.apache.org Received: (qmail 50270 invoked by uid 500); 25 Jun 2012 23:01:45 -0000 Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mapreduce-issues@hadoop.apache.org Delivered-To: mailing list mapreduce-issues@hadoop.apache.org Received: (qmail 50248 invoked by uid 99); 25 Jun 2012 23:01:45 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2012 23:01:45 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id AC55414283F for ; Mon, 25 Jun 2012 23:01:44 +0000 (UTC) Date: Mon, 25 Jun 2012 23:01:44 +0000 (UTC) From: "Alejandro Abdelnur (JIRA)" To: mapreduce-issues@hadoop.apache.org Message-ID: <190512225.53992.1340665304710.JavaMail.jiratomcat@issues-vm> In-Reply-To: <402652261.39420.1338904403498.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (MAPREDUCE-4317) Job view ACL checks are too permissive MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MAPREDUCE-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401004#comment-13401004 ] Alejandro Abdelnur commented on MAPREDUCE-4317: ----------------------------------------------- but the check for user '*null*' was not there, why are you introducing it? if the user is undefined it will be null, when do you expect the user to be the string '*null*'. Checking for *user == null* should be enough, no? > 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() { > 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 + "!

" + e.getMessage() + > "
Go back to JobTracker
"; > JSPUtil.setErrorAndForward(errMsg, request, response); > myJob.setViewAccess(false); > } catch (InterruptedException e) { > String errMsg = " Interrupted while trying to access " + jobid + > "
Go back to JobTracker
"; > 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