[ 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. {code} } else if (id.getScheme().equals("auth")) { // This is the "auth" id, so we have to expand it to the // authenticated ids of the requestor it.remove(); if (toAdd == null) { toAdd = new LinkedList<ACL>(); } boolean authIdValid = false; for (Id cid : authInfo) { AuthenticationProvider ap = ProviderRegistry.getProvider(cid.getScheme()); 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; } } {code} 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: {noformat} ➜ 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] WATCHER:: WatchedEvent state:AuthFailed type:None path:null WATCHER:: WatchedEvent state:SyncConnected type:None path:null [zk: hw10447.local(CONNECTED) 0] create /foo "" auth:hbase:cdrwa Acl is not valid : /foo {noformat} 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 (v6.3.15#6346)