Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Thu, 5 Feb 2015 22:25:37 +0000 (UTC)
From: "Chris Douglas (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12770237.1422318898000.272391.1423175137333@Atlassian.JIRA>
In-Reply-To: <JIRA.12770237.1422318898000@Atlassian.JIRA>
References: <JIRA.12770237.1422318898000@Atlassian.JIRA>
 <JIRA.12770237.1422318898459@arcas>
Subject: [jira] [Commented] (YARN-3100) Make YARN authorization pluggable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/YARN-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308126#comment-14308126 ] 

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 refreshQueue.

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
(v6.3.4#6332)