hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HADOOP-12799) Allow bypassing file owner check in SecureIOUtils when security is enabled
Date Fri, 12 Feb 2016 22:37:18 GMT
Gary Helmling created HADOOP-12799:
--------------------------------------

             Summary: Allow bypassing file owner check in SecureIOUtils when security is enabled
                 Key: HADOOP-12799
                 URL: https://issues.apache.org/jira/browse/HADOOP-12799
             Project: Hadoop Common
          Issue Type: Improvement
            Reporter: Gary Helmling


When secure authentication is enabled, SecureIOUtils enforces that the local file owner matches
the expected (authenticated) user when opening a file for read.  Effectively, this means that:
1) LinuxContainerExecutor must be configured for YARN when Hadoop security is enabled, 2)
all users running YARN jobs must be resolvable by the underlying OS.

While the check in SecureIOUtils.checkStat() protects against possible symlink attacks by
malicious local users, preventing it from being disabled makes it impossible to run with a
perimeter security model, where all access is strongly authenticated and only a select set
of trusted users are allowed to run YARN jobs.  Since it is possible to lock down who is allowed
to submit YARN jobs, this lack of flexibility seems unfortunate.

I'd like to propose adding a configuration option to allow disabling the local file owner
check.  It would remain enabled by default, but when disabled would allow running Hadoop with
strong authentication, but with relaxed security on YARN using DefaultContainerExecutor for
environments where resolving all users from the local OS is impractical.  For these situations,
it would of course need to be acceptable to mitigate the additional exposure to local file
attacks for YARN containers by controlling which users are allowed to submit YARN jobs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message