[
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: [email protected]
For additional commands, e-mail: [email protected]
