[
https://issues.apache.org/jira/browse/YARN-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244825#comment-16244825
]
Shane Kumpf edited comment on YARN-7430 at 11/8/17 10:14 PM:
-------------------------------------------------------------
{quote}
User foo should not allow to execute script owned by skumpf, unless skumpf
granted permission to run the script
{quote}
User foo doesn't execute the script owned by skumpf if we pass the user skumpf.
This is exactly how every container works today. We pass the user name and run
the entrypoint in the container as this user, overriding what the image has
set. This allows localization and logging to work. With the change to turn this
off, we let the image decide, but only for privileged containers. The result is
that any image that has "USER <username>" in it, must be modified.
{quote}
--user=0:0 does not mean privileged. It means the entry point is granted with
pseudo root privileges inside the container.
{quote}
Sorry, poorly worded. Do you think that the entry point process in a privileged
container should always run as root? if so, we should enforce that by setting
{{\-\-user=0:0}}.
I think there is a place for containers where we don't set the user, but for
those types to work, we'd need to get rid of all mounts and avoid overriding
the entrypoint ("vanilla containers").
was (Author: shaneku...@gmail.com):
{quote}
User foo should not allow to execute script owned by skumpf, unless skumpf
granted permission to run the script
{quote}
User foo doesn't execute the script owned by skumpf if we pass the user skumpf.
This is exactly how every container works today. We pass the user name and run
the entrypoint in the container as this user, overriding what the image has
set. This allows localization and logging to work. With the change to turn this
off, we let the image decide, but only for privileged containers. The result is
that any image that has "USER <username>" in it, must be modified.
{quote}
--user=0:0 does not mean privileged. It means the entry point is granted with
pseudo root privileges inside the container.
{quote}
Sorry, poorly worded. Do you think that the entry point process in a privileged
container should always run as root? if so, we should enforce that by setting
{{\-\-user=0:0}}.
I think there is a place for applications where we don't set the user, but for
those types to work, we'd need to get rid of all mounts and avoid overriding
the entrypoint ("vanilla containers").
> User and Group mapping are incorrect in docker container
> --------------------------------------------------------
>
> Key: YARN-7430
> URL: https://issues.apache.org/jira/browse/YARN-7430
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: security, yarn
> Affects Versions: 2.9.0, 3.0.0
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Blocker
> Attachments: YARN-7430.001.patch
>
>
> In YARN-4266, the recommendation was to use -u [uid]:[gid] numeric values to
> enforce user and group for the running user. In YARN-6623, this translated
> to --user=test --group-add=group1. The code no longer enforce group
> correctly for launched process.
> In addition, the implementation in YARN-6623 requires the user and group
> information to exist in container to translate username and group to uid/gid.
> For users on LDAP, there is no good way to populate container with user and
> group information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
