hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Updated: (MAPREDUCE-2096) Secure local filesystem IO from symlink vulnerabilities
Date Mon, 04 Oct 2010 05:57:35 GMT

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

Todd Lipcon updated MAPREDUCE-2096:
-----------------------------------

    Attachment: secure-files-authorized-jvm-fix.txt

In testing I came upon one spot where the new JVM authorization in this patch was incorrectly
triggered:

2010-10-03 22:30:36,252 WARN org.apache.hadoop.mapred.TaskRunner: attempt_201010032228_0001_m_000001_2
Reporting Diagnostics
java.io.IOException: JVM with mapred is not authorized for job_201010032228_0001
        at org.apache.hadoop.mapred.TaskTracker.ensureAuthorizedJVM(TaskTracker.java:3096)
        at org.apache.hadoop.mapred.TaskTracker.reportDiagnosticInfo(TaskTracker.java:3164)
        at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:232)

This patch fixes the above issue by having TaskRunner call to a version of reportDiagonsticInfo
that doesn't authorize the caller.

> Secure local filesystem IO from symlink vulnerabilities
> -------------------------------------------------------
>
>                 Key: MAPREDUCE-2096
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2096
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: jobtracker, security, tasktracker
>    Affects Versions: 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Blocker
>         Attachments: secure-files-9.txt, secure-files-authorized-jvm-fix.txt
>
>
> This JIRA is to contribute a patch developed on the private security@ mailing list.
> The vulnerability is that MR daemons occasionally open files that are located in a path
where the user has write access. A malicious user may place a symlink in place of the expected
file in order to cause the daemon to instead read another file on the system -- one which
the attacker may not naturally be able to access. This includes delegation tokens belong to
other users, log files, keytabs, etc.

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


Mime
View raw message