hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Kumpf (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-7430) User and Group mapping are incorrect in docker container
Date Wed, 08 Nov 2017 22:15:01 GMT

    [ 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: shanekumpf@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message