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 16:34:46 GMT

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

Eric Badger commented on YARN-4266:
-----------------------------------

[~tangzhankun], I tried out the most recent patch that you put up and I have a few comments.

{noformat}
+      if (disableUserRemapping) {
{noformat}
{noformat}
+      if (disableUserRemapping && targetUID != null) {
{noformat}
- Shouldn't {{disableUserRemapping}} be negated in these statements? We want to do the remapping
if {{disableUserRemapping}} is *not* disabled.

{noformat}
+        containerPredefinedUser = getDockerImageInfo("{{.Config.User}}", imageName, containerIdStr);
{noformat}
- There is no check to see whether {{containerPredefinedUser}} actually got set to anything.
It's possible for docker inspect to not return a predefined user. In this case, we will be
unable to do remapping and the usermod command will fail because the user will be blank. 

{noformat}
+        //get runAsUser's UID for container to usermod when init
+        if (!containerPredefinedUser.equals("root")) {
+          targetUID = getLocalUid(runAsUser);
+        }
{noformat}
- I think checking {{containerPredefinedUser}} misses some cases here. You may still want
the container to be run as a different user even if the predefined user is root. If we don't
remap when the predefined user is root, then anything written out to shared data volumes will
have messed up permissions outside of the container. 

{noformat}
+        String cmd = "\"usermod -o -u " + targetUID + " " + containerPredefinedUser
+            + " && su " + containerPredefinedUser + " bash -c '"
{noformat}
- It's not guaranteed that the predefined user has /bin/bash shell permissions. So it may
be prudent to add a {{-s /bin/bash}} to the usermod command.

Making the above changes I've been able to successfully submit and run jobs as multiple different
users without permissions issues. The only necessity seems to be that there be a predefined
user in the image that is being used. 

Additionally, this usermod approach doesn't currently deal with group permissions at all,
which could be an issue especially in multi-tenant clusters. 


> 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: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message