[ https://issues.apache.org/jira/browse/YARN-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391336#comment-15391336 ]
Zhankun Tang commented on YARN-5360: ------------------------------------ [~sidharta-s], although running a container as root have security implications by default, we can still use capabilities(already enabled in YARN-4258), selinux and other linux kernel features to ensure the root user in container has much less privileges than the real “root” in host. So for me, it is not unsafe. But as you mentioned, YARN's own complexity here prevents us from simply removing "--user" option. Then let's focus on resolving these barriers which enforces it and provide more flexible interface of what user to run the container. For discussion, I list them as below. We need more flexibility and we have these barriers to cross: * 1. Mounting /etc/passwd to container ** We should provide a way to toggle it since it override the original users defined in Docker image. It shouldn't be mounted by default. ButI think this already can be done by application thru YARN-4595. What we need to do is just remove /etc/passwd bind-mount after this JIRA closed. * 2. Exclusive permissions of local host files/directories mounted into Docker container, especially "launch_container.sh" ** One simple way to solve this is just change the related permissions. For instance, if unsecure mode, set 705 to launch_container.sh to allow other group user run it and set 707 to log dirs to allow others to write log. If secure mode, just set permissions as it is now. * 3. Side effects that if we change the running user, things like log aggregation would fail ** One simple way is that modify the YARN expects. For instance, don't expect log permission same with submitting user if unsecure mode but check it when secure mode. And solving above items shouldn’t affect the secure mode requirement on user. Behaviors in secure mode are just same as it is now. After solving these barriers, we can provide application the interface in unsecure mode: * an environment variable YARN_CONTAINER_RUNTIME_DOCKER_USER for application to specify the running user in unsecure mode Thoughts? > 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