[
https://issues.apache.org/jira/browse/YARN-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796533#comment-16796533
]
Eric Badger commented on YARN-9391:
-----------------------------------
bq. I think this issue is specific to the entry-point case where whitelist
variables override those specified in the image.
In what circumstances does it make sense for the docker container to use the
environment variables that are specified on the host? The docker image could be
wildly different than the layout on the host. I don't think that we can use the
assumption that the docker image and the host are going to have similar
layouts. So that makes me want to not use the environment variables of the NM
unless the job explicitly asks for them (or possibly not even then. Then they
would just specify them in the environment for their job).
> Disable PATH variable to be passed to Docker container
> ------------------------------------------------------
>
> Key: YARN-9391
> URL: https://issues.apache.org/jira/browse/YARN-9391
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Yang
> Priority: Major
>
> This is observed from using Apache NiFi docker image. It makes assumption
> that PATH variable contains /bin to reference to system utility. Where host
> YARN environment PATH variable is default to leaked into container by
> accident and not containing /bin path (default configuration). In general,
> it seems like node manager should block PATH variable from leaking into
> container. Not sure if there is a valid use case that host PATH variable
> must leak into container from docker point of view. From Hadoop point of
> view, if container is merely a chroot, and container is a mirror image of
> host worker dir. It is good to keep host PATH variable the same.
> Maybe we want to be more specific that block PATH variable to leak into
> Docker container, if it is using ENTRYPOINT only?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
