[
https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835724#comment-16835724
]
Kiran Kumar Maturi commented on PHOENIX-5269:
---------------------------------------------
[~tdsilva] [~apurtell] I have made the changes in PhoenixAccessController to
use check for permissions using AuthManager provided by AccessChecker. I have
tested it running TableDDLPermissionsIT.java it succeeds. I will be doing some
more testing and add test cases as well.
[~tdsilva] can you please review.
> 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.1-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)
