[
https://issues.apache.org/jira/browse/YARN-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383322#comment-15383322
]
Daniel Templeton edited comment on YARN-5360 at 7/19/16 12:16 AM:
------------------------------------------------------------------
I agree that UID isn't going to make things better. Usernames will be more
portable.
Running the container as root is not typically a security concern. That's the
magic promise of containers. Dropping the --user altogether is a partial
solution, though. I may want my container to run as a user that is unknown to
YARN and not specified in the Dockerfile. For that reason, allowing users
control over the --user option would be desirable.
The main issue is that the launch_container.sh script is owned by the job owner
with limited access. One common way around this issue is to pipe the contents
of the file to "docker run ... /bin/bash -c". That will work for the script,
but it might require some extra cleverness to use that approach to also bring
over the tokens file. Another way to get around the access issues is running
the container as root, thought that's a little limiting.
[~sidharta-s], what was the original reason that --user was forced for all
users?
was (Author: templedf):
I agree that UID isn't going to make things better. Usernames will be more
portable.
Running the container as root is not typically a security concern. That's the
magic promise of containers. Dropping the --user altogether is a partial
solution, though. I may want my container to run as a user that is unknown to
YARN and not specified in the Dockerfile. For that reason, allowing users
control over the --user option would be desirable.
The main issue is that the launch_container.sh script is owned by the job owner
with limited access. One common way around this issue is to pipe the contents
of the file to "docker run ... /bin/bash -c". That will work for the script,
but it might require some extra cleverness to use that approach to also bring
over the tokens file. Another way to get around the access issues is running
the container as root, thought that's a little limiting.
If we can't work out a way to allow the script to execute while leaving --user
configurable, the next best option would be YARN-4266 and requiring that the
user be specified in the Dockerfile.
[~sidharta-s], what was the original reason that --user was forced for all
users?
> Decouple host user and Docker container user
> --------------------------------------------
>
> Key: YARN-5360
> URL: https://issues.apache.org/jira/browse/YARN-5360
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Reporter: Zhankun Tang
> Assignee: Zhankun Tang
>
> There is *a dependency between job submitting user and the user in the Docker
> image* in LCE currently. For instance, in order to run the Docker container
> as yarn user, we can choose set the
> "yarn.nodemanager.linux-container-executor.nonsecure-mode.local-user" to yarn
> and leave
> "yarn.nodemanager.linux-container-executor.nonsecure-mode.limit-users"
> default (true). Then LCE will choose yarn ( UID maybe 1001) as the user
> running jobs.
> LCE will mount the generated launch_container.sh (owned by the running job
> user) and /etc/passwd (*current the code is mounting to container's
> /etc/password, I think it's a mistake*) into the Docker container and
> utilizes "docker run --user=<run_as_user>" option to get it done internally.
> Mounting /etc/passwd to the container is a not good choice due to override
> original users defined in Docker image. As far as I know, since Docker v1.8
> (or maybe earlier), the Docker run command "--user=" option accepts UID and
> *when passing UID, the user does not have to exist in the container*. So we
> could use UID instead of user name to construct the Docker run command to
> eliminate the dependency that create the same user in the Docker image. This
> enables LCE the ability to launch any Docker container safely regardless what
> users in it.
> But this is not enough to decouple host user and Docker container user. The
> final solution we are searching for are focused on allowing users to run
> their Docker images flexibly without involving dependencies of YARN and make
> sure the container won't bring in security risk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
