[
https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16290084#comment-16290084
]
Appy commented on HBASE-19483:
------------------------------
At first I thought that [~stack]'s suggestion was great, but the current
approach was fine too, after all, it was just exposing RSGroupInfo which was
public.
But then looking around, found {{RSGroupAdminEndpoint implements
MasterCoprocessor}}. RSGroupAdminServer is itself a coprocessor in a separate
package! No no to adding rsgroup hooks in hbase-server.
Looking around more, the absolute proper way to do this would be:
1) moving require*() fns to a new class AccessChecker (contains
TableAuthManager) in hbase-server
2) Create it's instance from RSGroupAdminServer
Then directly do auth checks from within rsgroup code.
Doesn't look much work. What do you think?
(If we do go this path, would suggest doing AC change and RSGroup change in
separate jiras)
> Add proper privilege check for rsgroup commands
> -----------------------------------------------
>
> Key: HBASE-19483
> URL: https://issues.apache.org/jira/browse/HBASE-19483
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: Guangxu Cheng
> Fix For: 1.4.1, 1.5.0, 2.0.0-beta-1
>
> Attachments: HBASE-19483.master.001.patch,
> HBASE-19483.master.002.patch, HBASE-19483.master.003.patch
>
>
> Currently list_rsgroups command can be executed by any user.
> This is inconsistent with other list commands such as list_peers and
> list_peer_configs.
> We should add proper privilege check for list_rsgroups command.
> privilege check should be added for get_table_rsgroup / get_server_rsgroup /
> get_rsgroup commands.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
