[
https://issues.apache.org/jira/browse/YARN-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065414#comment-16065414
]
Eric Badger commented on YARN-4266:
-----------------------------------
bq. I'm not really a fan of hard coding bind mounts like we've done for
/sys/fs/cgroup if we can help it.
Yea I'm really not a fan either. I would strongly prefer a better, cleaner
solution to this problem if there is one.
bq. Are you aware of any security implications with this socket mounted
read-only in the container?
I haven't done any research into it, but I imagine bind-mounting a socket would
have more security implications than a regular directory. If we decide this
route is worth delving into, then I will do my due diligence of trying to
identify security risks and whether they are acceptable or not.
bq. Also, are there any clients that might be required to be installed in the
container depending on how nsswitch is configured?
If you bind mount /var/run/nscd then it will use the process listening on that
socket. This will end up using nsswitch on the host, not in the container. So
it would completely leverage host services, not services within the container.
This actually makes things nice for remote user lookups, because it can use the
host's cache. This means that the container won't have to do a remote user
lookup every time a container is started, assuming that it's in the host's user
cache, if it has one (such as nscd). So I don't believe that any extra services
would have to be installed within the container for this to be used, only on
the host. And if no service is listening on the nscd socket, then the user
lookup would do the user lookup like it normally would.
bq. Alternatively, why does MRAppMaster do the user lookup in this case? Is
there a way to remove that limitation? Are you finding other AM's have a
similar issue?
I'm looking into this. I'm hoping that we can get around this so that we can
optionally add the bind mount, but not require it for the {{--user}} option. I
have not yet tested other AMs.
> 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: luhuichun
> Attachments: YARN-4266.001.patch, 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
