[
https://issues.apache.org/jira/browse/HBASE-14169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649932#comment-14649932
]
Andrew Purtell commented on HBASE-14169:
----------------------------------------
bq. I think we should follow the same pattern of grant/revoke. The client goes
to the ACL endpoint, and the ACL endpoint propagate the request.
+1
The AccessController instance running on the ACL table handles grant and revoke
commands and takes care of further housekeeping behind the scenes. Today we
propagate the change using zookeeper, but we want to move that to the
ProcedureV2 framework for better guarantees. An API like this would derive the
same benefit from that work, but only if we stick to the current pattern.
bq. allowing global admin to refresh super user groups can introduce
vulnerability as it introduces the possibility for global admin to gain super
user privileges
Also, +1, it's a theoretical risk but makes sense that only a superuser can
trigger a change of the superuser configuration.
> API to refreshSuperUserGroupsConfiguration
> ------------------------------------------
>
> Key: HBASE-14169
> URL: https://issues.apache.org/jira/browse/HBASE-14169
> Project: HBase
> Issue Type: New Feature
> Reporter: Francis Liu
> Assignee: Francis Liu
> Attachments: HBASE-14169.patch
>
>
> For deployments that use security. User impersonation (AKA doAs()) is needed
> for some services (ie Stargate, thriftserver, Oozie, etc). Impersonation
> definitions are defined in a xml config file and read and cached by the
> ProxyUsers class. Calling this api will refresh cached information,
> eliminating the need to restart the master/regionserver whenever the
> configuration is changed.
> Implementation just adds another method to AccessControlService.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
