[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401973#comment-16401973
]
Jason Lowe commented on YARN-7654:
----------------------------------
bq. As you can see the struggle with flipping code for execv, this is the
reason that this patch takes a long time to develop. If we want to separate
execv call from getting a working version, then patch 001 would be reasonable
to commit.
Patch 001 isn't reasonable to commit because it's executing untrusted shell
constructs as root. I agree that the execv work makes implementing the entry
point feature easier to secure. What I'm advocating is separating the execv
work into a separate JIRA, since it can stand on its own and has an additional
security benefit even without the entry point feature. This feature can depend
upon the execv JIRA. That makes the overall work easier to review since it
doesn't come in as one big patch.
> Support ENTRY_POINT for docker container
> ----------------------------------------
>
> Key: YARN-7654
> URL: https://issues.apache.org/jira/browse/YARN-7654
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Affects Versions: 3.1.0
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Blocker
> Attachments: YARN-7654.001.patch, YARN-7654.002.patch,
> YARN-7654.003.patch
>
>
> Docker image may have ENTRY_POINT predefined, but this is not supported in
> the current implementation. It would be nice if we can detect existence of
> {{launch_command}} and base on this variable launch docker container in
> different ways:
> h3. Launch command exists
> {code}
> docker run [image]:[version]
> docker exec [container_id] [launch_command]
> {code}
> h3. Use ENTRY_POINT
> {code}
> docker run [image]:[version]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
