You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Eric Yang (JIRA)" <ji...@apache.org> on 2018/10/10 00:26:00 UTC
[jira] [Comment Edited] (YARN-8569) Create an interface to provide
cluster information to application
[ https://issues.apache.org/jira/browse/YARN-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644277#comment-16644277 ]
Eric Yang edited comment on YARN-8569 at 10/10/18 12:25 AM:
------------------------------------------------------------
{quote}
1) We use use set_user before the method to drop privileges.
{quote}
Good catch, check_user will be applied in the next patch.
{quote}
2) Root privilege should be only used by open_file_as_nm.
{quote}
In sync_yarn_sysfs, check_nm_local_dir make sure the nm_local_dir is owned by yarn user. This ensure the copy file operation is safe guarded against possible path exploits. This is equivalent to next point to ensure nm local dirs are indeed owned by yarn.
{quote}
3) We should check all in/out file paths under local dirs defined by container_executor.cfg.
{quote}
Initialize container, launch container, launch docker container, they are all using nm-local-dirs path passed from node manager to container executor. There is no definition of yarn.nodemanager.local-dirs in container-executor.cfg file. For containing the scope of this JIRA, I opened YARN-8863 to track the proposed global pattern change.
{quote}
4) Regarding to API, I think we should allow filename specified.
{quote}
I am concerned that tokens are localized in the same nmPrivate directory. If filename can be specified, it may increase vulnerable surface for attack to use the REST API to copy hdfs token into sysfs directory. This appears to be innocent action is unsafe. For untrusted docker containers, we prevent mounting of token file into container, and run it as a sandbox. If we allow this action to happen, the untrusted container can acquire access to HDFS by calling sync yarn sysfs REST API.
{quote}5) For the mounted dir for container, for app-level information, I would prefer to put under ...sys/fs/app/<file> instead of ...sys/fs/<file> since we want to support per-container information in the future.{quote}
Point 4 is a bit concerning to me. I am error on side of caution. Therefore, I do not plan to make arbitrary filename change in this JIRA. Please open a separate one, if you feel strongly about supporting custom filename in the rest API.
was (Author: eyang):
{quote}
1) We use use set_user before the method to drop privileges.
{quote}
Good catch, check_user will be applied in the next patch.
{quote}
2) Root privilege should be only used by open_file_as_nm.
{quote}
In sync_yarn_sysfs, check_nm_local_dir make sure the nm_local_dir is owned by yarn user. This ensure the copy file operation is safe guarded against possible path exploits. This is equivalent to next point to ensure nm local dirs are indeed owned by yarn.
{quote}
3) We should check all in/out file paths under local dirs defined by container_executor.cfg.
{quote}
Initialize container, launch container, launch docker container, they are all using nm-local-dirs path passed from node manager to container executor. There is no definition of yarn.nodemanager.local-dirs in container-executor.cfg file. For containing the scope of this JIRA, I opened YARN-8863 to track the proposed global pattern change.
{quote}
4) Regarding to API, I think we should allow filename specified.
{quote}
I am concerned that tokens are localized in the same nmPrivate directory. If filename can be specified, it may increase vulnerable surface for attack to use the REST API to copy hdfs token into sysfs directory. I don't unsure this appear to be innocent action is safe.
{quote}5) For the mounted dir for container, for app-level information, I would prefer to put under ...sys/fs/app/<file> instead of ...sys/fs/<file> since we want to support per-container information in the future.{quote}
Point 4 is a bit concerning to me. I am error on side of caution. Therefore, I do not plan to make arbitrary filename change in this JIRA. Please open a separate one, if you feel strongly about supporting custom filename in the rest API.
> Create an interface to provide cluster information to application
> -----------------------------------------------------------------
>
> Key: YARN-8569
> URL: https://issues.apache.org/jira/browse/YARN-8569
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Major
> Labels: Docker
> Attachments: YARN-8569 YARN sysfs interface to provide cluster information to application.pdf, YARN-8569.001.patch, YARN-8569.002.patch, YARN-8569.003.patch, YARN-8569.004.patch, YARN-8569.005.patch, YARN-8569.006.patch, YARN-8569.007.patch, YARN-8569.008.patch, YARN-8569.009.patch, YARN-8569.010.patch, YARN-8569.011.patch
>
>
> Some program requires container hostnames to be known for application to run. For example, distributed tensorflow requires launch_command that looks like:
> {code}
> # On ps0.example.com:
> $ python trainer.py \
> --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
> --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
> --job_name=ps --task_index=0
> # On ps1.example.com:
> $ python trainer.py \
> --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
> --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
> --job_name=ps --task_index=1
> # On worker0.example.com:
> $ python trainer.py \
> --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
> --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
> --job_name=worker --task_index=0
> # On worker1.example.com:
> $ python trainer.py \
> --ps_hosts=ps0.example.com:2222,ps1.example.com:2222 \
> --worker_hosts=worker0.example.com:2222,worker1.example.com:2222 \
> --job_name=worker --task_index=1
> {code}
> This is a bit cumbersome to orchestrate via Distributed Shell, or YARN services launch_command. In addition, the dynamic parameters do not work with YARN flex command. This is the classic pain point for application developer attempt to automate system environment settings as parameter to end user application.
> It would be great if YARN Docker integration can provide a simple option to expose hostnames of the yarn service via a mounted file. The file content gets updated when flex command is performed. This allows application developer to consume system environment settings via a standard interface. It is like /proc/devices for Linux, but for Hadoop. This may involve updating a file in distributed cache, and allow mounting of the file via container-executor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org