hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Badger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4266) Allow whitelisted users to disable user re-mapping/squashing when launching docker containers
Date Fri, 03 Mar 2017 22:17:45 GMT

    [ https://issues.apache.org/jira/browse/YARN-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15895132#comment-15895132

Eric Badger commented on YARN-4266:

[~templedf], I think you're misunderstanding what I was saying. When we instantiate the {{DockerRunCommand}},
we give it a user to run as. In this user remapping case, we've been setting that user to
root so that we have permissions to perform the usermod remapping in the container. I'm saying,
however, that we could set that use to the UID and GID of the user that submitted the job
(i.e. {{runAsUser}} in the code). 

So let's say user foo:1000:1000 submitted a job. The NM will create the launch_container.sh
script assuming user foo. Then we will go to launch the docker container. When we instantiate
the {{DockerRunCommand}}, we would pass it the output of {{id -u}} and {{id -g}}. This sort
of thing is already being done in [~tangzhankun]'s patch to get {{targetUID}}. The result
would give us a command that looks like: {{docker run --user=1000:1000 ...}}. There isn't
a security hole here that I can see because the user in the container will have the same UID/GID
as the user that submitted the job. Inside the container, the username associated with the
UID doesn't really matter. Outside of the container, everything written by the user in the
container will have the same UID. A downside would be that the username inside of the container
isn't meaningful and could be potentially very misleading to those who are unaware of how
this is all being done. 

I've tested the --user=UID:GID option locally on a single-node cluster and have been successful.
Files/logs/etc. written in the container using are owned by the user that submitted the job,
which is the UID:GID given in the --user option (foo:1000:1000 in the example above). 

There also isn't a problem with usernames being numbers (which the image could map to arbitrary
UID/GIDs) because docker interprets all numbers in the --user option as UID/GIDs. I tested
this locally to make sure. So even if there is a user named "2000" (with UID != 2000), the
command {{docker run --user=2000}} will create a new user with UID 2000. 

> Allow whitelisted users to disable user re-mapping/squashing when launching docker containers
> ---------------------------------------------------------------------------------------------
>                 Key: YARN-4266
>                 URL: https://issues.apache.org/jira/browse/YARN-4266
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: Sidharta Seethana
>            Assignee: Zhankun Tang
>         Attachments: YARN-4266.001.patch, YARN-4266_Allow_whitelisted_users_to_disable_user_re-mapping.pdf,
YARN-4266_Allow_whitelisted_users_to_disable_user_re-mapping_v2.pdf, YARN-4266_Allow_whitelisted_users_to_disable_user_re-mapping_v3.pdf,
> Docker provides a mechanism (the --user switch) that enables us to specify the user the
container processes should run as. We use this mechanism today when launching docker containers
. In non-secure mode, we run the docker container based on `yarn.nodemanager.linux-container-executor.nonsecure-mode.local-user`
and in secure mode, as the submitting user. However, this mechanism breaks down with a large
number of 'pre-created' images which don't necessarily have the users available within the
image. Examples of such images include shared images that need to be used by multiple users.
We need a way in which we can allow a pre-defined set of users to run containers based on
existing images, without using the --user switch. There are some implications of disabling
this user squashing that we'll need to work through : log aggregation, artifact deletion etc.,

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message