[
https://issues.apache.org/jira/browse/YARN-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417744#comment-17417744
]
Eric Payne commented on YARN-1115:
----------------------------------
bq. I re-defined the user variable from String to be UserGroupInformation in
order to reduce the number of code changes. Maybe that wasn't the best approach.
Actually, that statement is inaccurate. I didn't change String to
UserGroupInformation. The String variable is still {{user}} and contains the
user's short name. The {{userUgi}} variable is of UserGroupInformation type,
and contains the whole set of UGI information that is available when the job
was submitted. I then modified the signatures of the methods in the call chain
to pass the whole UGI so that when the user UGI gets to the Capacity Scheduler,
it can check for either the real user or the proxied user.
bq. Yes, you are right. It is confusing, especially when you say it that way
While I do understand and agree that it is confusing, I think it is still set
up correctly. {{user}} is always the user for whom YARN will be running the
application. It's just that sometimes that will be the real user and sometimes
that will be the proxied user. Unfortunately, although this explanation is
accurate, it is still confusing.
> Provide optional means for a scheduler to check real user ACLs
> --------------------------------------------------------------
>
> Key: YARN-1115
> URL: https://issues.apache.org/jira/browse/YARN-1115
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: capacity scheduler, scheduler
> Affects Versions: 2.8.5
> Reporter: Eric Payne
> Priority: Major
> Attachments: YARN-1115.001.patch
>
>
> In the framework for secure implementation using UserGroupInformation.doAs
> (https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html),
> a trusted superuser can submit jobs on behalf of another user in a secure
> way. In this framework, the superuser is referred to as the real user and the
> proxied user is referred to as the effective user.
> Currently when a job is submitted as an effective user, the ACLs for the
> effective user are checked against the queue on which the job is to be run.
> Depending on an optional configuration, the scheduler should also check the
> ACLs of the real user if the configuration to do so is set.
> For example, suppose my superuser name is super, and super is configured to
> securely proxy as joe. Also suppose there is a Hadoop queue named ops which
> only allows ACLs for super, not for joe.
> When super proxies to joe in order to submit a job to the ops queue, it will
> fail because joe, as the effective user, does not have ACLs on the ops queue.
> In many cases this is what you want, in order to protect queues that joe
> should not be using.
> However, there are times when super may need to proxy to many users, and the
> client running as super just wants to use the ops queue because the ops queue
> is already dedicated to the client's purpose, and, to keep the ops queue
> dedicated to that purpose, super doesn't want to open up ACLs to joe in
> general on the ops queue. Without this functionality, in this case, the
> client running as super needs to figure out which queue each user has ACLs
> opened up for, and then coordinate with other tasks using those queues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
