[
https://issues.apache.org/jira/browse/YARN-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490997#comment-16490997
]
Shane Kumpf edited comment on YARN-8342 at 5/25/18 4:50 PM:
------------------------------------------------------------
{quote}Allow exemption to bind-mount launch-container.sh for untrusted yarn
mode, and not drop launch_command.{quote}
The launch script typically handles symlinks, environment variables, prelaunch
output, etc. Will this be compatible if all mounts are removed? Wouldn't it be
easier to skip the launch script and just pass the "launch_command" from the
Services API? The "exec bash" in the launch script seems like it would be
problematic for this use case too.
{quote}The current implementation will block system auditing inside docker
container with selinux turned on.{quote}
I thought this was related to enabling "no-new-privileges", which we aren't
setting by default. Is there another case here that breaks SELinux?
{quote}Change the name docker.privileged-containers.registries back to
docker.trusted.registries. Images outside of trusted.registries are
disallowed.{quote}
I think that these could be treated as two separate items. Changing the name
docker.privileged-containers.registries back to docker.trusted.registries could
be done here and we could maintain the "untrusted sandbox" feature. I still
don't love using the word "trusted" as it's overloaded too (e.g. "Docker
Trusted Registry", "content trust", etc) but I certainly prefer "trusted" over
"privileged", so I'm +1 for "trusted" here unless someone has a better name.
YARN-8343 could handle the while list independent of this feature.
So I guess I'm in favor of some form of #1 and the first half of #2 being
handled here.
was (Author: [email protected]):
{quote}Allow exemption to bind-mount launch-container.sh for untrusted yarn
mode, and not drop launch_command.{quote}
The launch script typically handles symlinks, environment variables, prelaunch
output, etc. Will this be compatible if all mounts are removed? Wouldn't it be
easier to skip the launch script and just pass the "launch_command" from the
Services API? The "exec bash" in the launch script seems like it would be
problematic for this use case too.
{quote}The current implementation will block system auditing inside docker
container with selinux turned on.{quote}
I thought this was related to enabling "no-new-privileges", which we aren't
setting by default. Is there another case here that breaks SELinux?
{quote}Change the name docker.privileged-containers.registries back to
docker.trusted.registries. Images outside of trusted.registries are
disallowed.{code}
I think that these could be treated as two separate items. Changing the name
docker.privileged-containers.registries back to docker.trusted.registries could
be done here and we could maintain the "untrusted sandbox" feature. I still
don't love using the word "trusted" as it's overloaded too (e.g. "Docker
Trusted Registry", "content trust", etc) but I certainly prefer "trusted" over
"privileged", so I'm +1 for "trusted" here unless someone has a better name.
YARN-8343 could handle the while list independent of this feature.
So I guess I'm in favor of some form of #1 and the first half of #2 being
handled here.
> Using docker image from a non-privileged registry, the launch_command is not
> honored
> ------------------------------------------------------------------------------------
>
> Key: YARN-8342
> URL: https://issues.apache.org/jira/browse/YARN-8342
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Wangda Tan
> Assignee: Eric Yang
> Priority: Critical
> Labels: Docker
> Attachments: YARN-8342.001.patch
>
>
> During test of the Docker feature, I found that if a container comes from
> non-privileged docker registry, the specified launch command will be ignored.
> Container will success without any log, which is very confusing to end users.
> And this behavior is inconsistent to containers from privileged docker
> registries.
> cc: [~eyang], [[email protected]], [~ebadger], [~jlowe]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
