Chris Douglas commented on YARN-3100:

bq.  The reinitializeQueues looks to be transactional, it instantiates all new 
sub queues first and then update the root queue and child queues accordingly. 
And the checkAccess chain will compete the same scheduler lock with the 

If there's a queue with root _Q_, say we're constructing _Q'_. In the current 
patch, the {{YarnAuthorizationProvider}} singleton instance will get calls to 
{{setPermission()}} during construction of _Q'_. These (1) will be observable 
by readers of _Q_ who share the instance. I agree that if construction of _Q'_ 
fails then it won't get installed, but (2) _Q_ will run with a mix of _Q'_ and 
_Q_ ACLs because each call to {{setPermission()}} overwrites what was installed 
for _Q_.

I'm curious if (1) and (2) are an artifact of the new plugin architecture or if 
this is also happens in the existing code. Not for external implementations, 
but for the {{Default\*}} one.

bq. Alternatively, the plug-in can choose to add new acl via the setPermission 
when refreshQueue is invoked, but not to replace existing acl. Also, whether to 
add new or update or no, this is something that plug-in itself can decide or 
make it configurable by user.

Maybe I'm being dense, but I don't see how a plugin could implement those 
semantics cleanly. {{YarnAuthorizationProvider}} forces the instance to be a 
singleton, and it gets some sequence of calls to {{setPermission()}}. Since 
queues can't be deleted in the CS, I suppose it could track the sequence of 
calls that install ACLs and only publish new ACLs when it's received updates 
for everything, but that could still yield (2) if the refresh adds new queues 
before the refresh fails.

> Make YARN authorization pluggable
> ---------------------------------
>                 Key: YARN-3100
>                 URL: https://issues.apache.org/jira/browse/YARN-3100
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Jian He
>            Assignee: Jian He
>         Attachments: YARN-3100.1.patch, YARN-3100.2.patch
> The goal is to have YARN acl model pluggable so as to integrate other 
> authorization tool such as Apache Ranger, Sentry.
> Currently, we have 
> - admin ACL
> - queue ACL
> - application ACL
> - time line domain ACL
> - service ACL
> The proposal is to create a YarnAuthorizationProvider interface. Current 
> implementation will be the default implementation. Ranger or Sentry plug-in 
> can implement  this interface.
> Benefit:
> -  Unify the code base. With the default implementation, we can get rid of 
> each specific ACL manager such as AdminAclManager, ApplicationACLsManager, 
> QueueAclsManager etc.
> - Enable Ranger, Sentry to do authorization for YARN. 

This message was sent by Atlassian JIRA

Reply via email to