[
https://issues.apache.org/jira/browse/MAPREDUCE-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401032#comment-13401032
]
Karthik Kambatla commented on MAPREDUCE-4317:
---------------------------------------------
In the following code snippet from TestWebUIAuthorization, new URL() takes in
userName. When the userName is null, the URL sees it as "null". In
checkAccessAndGetJob, we read the username from this string and get "null" and
not null.
The test fails when I check only for user == null.
{code}
static int getHttpStatusCode(String urlstring, String userName,
String method) throws IOException {
LOG.info("Accessing " + urlstring + " as user " + userName);
URL url = new URL(urlstring + "&user.name=" + userName);
HttpURLConnection connection = (HttpURLConnection)url.openConnection();
connection.setRequestMethod(method);
if (method.equals("POST")) {
String encodedData = "action=kill&user.name=" + userName;
connection.setRequestProperty("Content-Type",
"application/x-www-form-urlencoded");
connection.setRequestProperty("Content-Length",
Integer.toString(encodedData.length()));
connection.setDoOutput(true);
OutputStream os = connection.getOutputStream();
os.write(encodedData.getBytes());
}
connection.connect();
return connection.getResponseCode();
}
{code}
> 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
