[
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,
> YARN-4266-branch-2.8.001.patch
>
>
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
