[ 
https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Kumar Maturi updated PHOENIX-5269:
----------------------------------------
    Attachment:     (was: PHOENIX-5269-4.14.1-HBase-1.4.patch)

> PhoenixAccessController should use AccessChecker instead of 
> AccessControlClient for permission checks
> -----------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5269
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5269
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.14.1, 4.14.2
>            Reporter: Andrew Purtell
>            Assignee: Kiran Kumar Maturi
>            Priority: Critical
>         Attachments: PHOENIX-5269-4.14-HBase-1.4.patch
>
>
> PhoenixAccessController should use AccessChecker instead of 
> AccessControlClient for permission checks. 
> In HBase, every RegionServer's AccessController maintains a local cache of 
> permissions. At startup time they are initialized from the ACL table. 
> Whenever the ACL table is changed (via grant or revoke) the AC on the ACL 
> table "broadcasts" the change via zookeeper, which updates the cache. This is 
> performed and managed by TableAuthManager but is exposed as API by 
> AccessChecker. AccessChecker is the result of a refactor that was committed 
> as far back as branch-1.4 I believe.
> Phoenix implements its own access controller and is using the client API 
> AccessControlClient instead. AccessControlClient does not cache nor use the 
> ZK-based cache update mechanism, because it is designed for client side use.
> The use of AccessControlClient instead of AccessChecker is not scalable. 
> Every permissions check will trigger a remote RPC to the ACL table, which is 
> generally going to be a single region hosted on a single RegionServer. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to