hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17717) Incorrect ZK ACL set for HBase superuser
Date Thu, 02 Mar 2017 17:12:45 GMT

    [ https://issues.apache.org/jira/browse/HBASE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15892627#comment-15892627

Josh Elser commented on HBASE-17717:

bq. So it only replaces auth with sasl iff the user principal matches with the current user

Ok, I think I got to the bottom of this. {{PrepRequestProcessor#fixupACL(List, List)}} is
what is doing this ZK server-side.

            } else if (id.getScheme().equals("auth")) {
                // This is the "auth" id, so we have to expand it to the
                // authenticated ids of the requestor
                if (toAdd == null) {
                    toAdd = new LinkedList<ACL>();
                boolean authIdValid = false;
                for (Id cid : authInfo) {
                    AuthenticationProvider ap =
                    if (ap == null) {
                        LOG.error("Missing AuthenticationProvider for "
                                + cid.getScheme());
                    } else if (ap.isAuthenticated()) {
                        authIdValid = true;
                        toAdd.add(new ACL(a.getPerms(), cid));
                if (!authIdValid) {
                    return false;

When the ACL is for {{auth}}, it looks at the authentication for the user making this request
({{cid}}) and sets the ACL to be the scheme and user of the current user (thus, {{sasl:hbase}}).

We can confirm that when there is no authentication, an auth scheme ACL is rejected:

➜ jelser@hw10447.local % kdestroy
➜ jelser@hw10447.local % zkCli.sh -server hw10447.local
Connecting to hw10447.local
Welcome to ZooKeeper!
JLine support is enabled
[zk: hw10447.local(CONNECTING) 0]

WatchedEvent state:AuthFailed type:None path:null


WatchedEvent state:SyncConnected type:None path:null

[zk: hw10447.local(CONNECTED) 0] create /foo "" auth:hbase:cdrwa
Acl is not valid : /foo

Just to confirm: given the above, [~enis], you're still +1?

> Incorrect ZK ACL set for HBase superuser
> ----------------------------------------
>                 Key: HBASE-17717
>                 URL: https://issues.apache.org/jira/browse/HBASE-17717
>             Project: HBase
>          Issue Type: Bug
>          Components: security, Zookeeper
>            Reporter: Shreya Bhat
>            Assignee: Josh Elser
>             Fix For: 2.0.0, 1.3.1, 1.1.10, 1.2.6
>         Attachments: HBASE-17717.001.patch
> Shreya was doing some testing of a deploy of HBase, verifying that the ZK ACLs were actually
set as we expect (yay, security).
> She noticed that, in some cases, we were seeing multiple ACLs for the same user.
> {noformat}
> 'world,'anyone
> : r
> 'sasl,'hbase
> : cdrwa
> 'sasl,'hbase
> : cdrwa
> {noformat}
> After digging into this (and some insight from the mighty [~enis]), we realized that
this was happening because of an overridden value for {{hbase.superuser}}. However, the ACL
value doesn't match what we'd expect to see (as hbase.superuser was set to {{cstm-hbase}}).
> After digging into this code, it seems like the {{auth}} ACL scheme in ZooKeeper does
not work as we expect.
> {code}
>       if (superUser != null) {
>         acls.add(new ACL(Perms.ALL, new Id("auth", superUser)));
>       }
> {code}
> In the above, the {{"auth"}} scheme ignores any provided "subject" in the {{Id}} object.
It *only* considers the authentication of the current connection. As such, our usage of this
never actually sets the ACL for the superuser correctly.

This message was sent by Atlassian JIRA

View raw message