[
https://issues.apache.org/jira/browse/ZOOKEEPER-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040489#comment-18040489
]
zhanglu153 commented on ZOOKEEPER-4996:
---------------------------------------
When the zk client in hbase creates a znode, the ACL list passed in is created
using the create ACL method. Different permissions are added based on whether
the znode is readable. We did not use hbase supper user.
* CREATOR_ALL_ACL、READ_ACL_UNSAFE
* CREATOR_ALL_ACL
{code:java}
public static ArrayList<ACL> createACL(ZooKeeperWatcher zkw, String node,
boolean isSecureZooKeeper) {
if (!node.startsWith(zkw.baseZNode)) {
return Ids.OPEN_ACL_UNSAFE;
}
if (isSecureZooKeeper) {
ArrayList<ACL> acls = new ArrayList<ACL>();
// add permission to hbase supper user
String[] superUsers =
zkw.getConfiguration().getStrings(Superusers.SUPERUSER_CONF_KEY);
String hbaseUser = null;
try {
hbaseUser = UserGroupInformation.getCurrentUser().getShortUserName();
} catch (IOException e) {
LOG.debug("Could not acquire current User.", e);
}
if (superUsers != null) {
List<String> groups = new ArrayList<String>();
for (String user : superUsers) {
if (AuthUtil.isGroupPrincipal(user)) {
// TODO: Set node ACL for groups when ZK supports this feature
groups.add(user);
} else {
if(!user.equals(hbaseUser)) {
acls.add(new ACL(Perms.ALL, new Id("sasl", user)));
}
}
}
if (!groups.isEmpty()) {
LOG.warn("Znode ACL setting for group " + groups
+ " is skipped, Zookeeper doesn't support this feature presently.");
}
}
// Certain znodes are accessed directly by the client,
// so they must be readable by non-authenticated clients
if (zkw.isClientReadable(node)) {
acls.addAll(Ids.CREATOR_ALL_ACL);
acls.addAll(Ids.READ_ACL_UNSAFE);
} else {
acls.addAll(Ids.CREATOR_ALL_ACL);
}
return acls;
} else {
return Ids.OPEN_ACL_UNSAFE;
}
} {code}
We found that when the zk server creates znode or setACL, it calls
org.apache.zookeeper.server.PrepRequestProcessor#fixupACL method to attempt to
correct the ACL, with the aim of replacing the auth schema with an
authenticated user, such as sasl or digest. According to code analysis and test
case validation, only when skipACL is set to true on the zk server to bypass
the fixupACL correction step, can the situation where 'auth': cdrwa has not
been replaced with an authenticated user be reproduced. But in our zk server,
skipACL always defaults to false. What other scenarios can cause multiple znode
ACLs to have auth schema?
{code:java}
private boolean fixupACL(List<Id> authInfo, List<ACL> acl) {
if (skipACL) {
return true;
}
if (acl == null || acl.size() == 0) {
return false;
}
Iterator<ACL> it = acl.iterator();
LinkedList<ACL> toAdd = null;
while (it.hasNext()) {
ACL a = it.next();
Id id = a.getId();
if (id.getScheme().equals("world") && id.getId().equals("anyone")) {
// wide open
} 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;
}
} else {
AuthenticationProvider ap = ProviderRegistry.getProvider(id
.getScheme());
if (ap == null) {
return false;
}
if (!ap.isValid(id.getId())) {
return false;
}
}
}
if (toAdd != null) {
for (ACL a : toAdd) {
acl.add(a);
}
}
return acl.size() > 0;
} {code}
> The appearance of the 'auth' schema leads to invalid znode authentication
> -------------------------------------------------------------------------
>
> Key: ZOOKEEPER-4996
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4996
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.14
> Reporter: zhanglu153
> Priority: Major
> Attachments: image-2025-11-25-10-51-03-165.png
>
>
> After calling getACL, multiple znodes returned auth schema, causing the
> client to throw NoAuth exception.
> The operation steps are as follows：
> * Configure in jaas.conf：
> {code:java}
> Client {
> com.sun.security.auth.module.Krb5LoginModule required
> useKeyTab=true
> keyTab="/cloud/service/zookeeper/conf/hbase.keytab"
> storeKey=true
> useTicketCache=false
> principal="[email protected]";
> }; {code}
> * zkCli.sh server 192.168.180.23 performs hbase user authentication, and it
> can be found that there are some znodes with incorrect permissions, use
> Zookeeper super administrator to query the permissions of znode with
> incorrect permissions. !image-2025-11-25-10-51-03-165.png!
> *
> {code:java}
> getAcl /hbase/replication/peers
> 'auth,'
> : cdrwa
> getAcl /hbase/hbaseid
> 'auth,'
> : cdrwa
> 'world,'anyone
> : r{code}
> There are the following znodes with permission issues, including some znodes
> for hive in addition to hbase：
> * /hbase/replication/peers 'auth,': cdrwa
> * /hbase/replication/rs 'auth,': cdrwa
> * /hbase/table-lock/hdp_ns:spark_test 'auth,': cdrwa
> * /hbase/flush-table-proc/abort 'auth,': cdrwa
> * /hbase/flush-table-proc/acquired 'auth,': cdrwa
> * /hbase/flush-table-proc/reached 'auth,': cdrwa
> * /hbase/online-snapshot/abort 'auth,': cdrwa
> * /hbase/online-snapshot/acquired 'auth,': cdrwa
> * /hbase/online-snapshot/reached 'auth,': cdrwa
> * /hbase/tokenauth/keys 'auth,': cdrwa
> * /hbase/tokenauth/keys/22 'auth,': cdrwa
> * /hbase/tokenauth/keys/23 'auth,': cdrwa
> * /hbase/tokenauth/keys/24 'auth,': cdrwa
> * /hbase/tokenauth/keys/18 'auth,': cdrwa
> * /hbase/tokenauth/keys/19 'auth,': cdrwa
> * /hbase/tokenauth/keys/20 'auth,': cdrwa
> * /hbase/tokenauth/keys/21 'auth,': cdrwa
> * /hbase/recovering-regions 'auth,': cdrwa
> * /hbase/draining 'auth,':
> cdrwa
> * /hbase/namespace 'auth,': cdrwa
> * /hbase/namespace/default 'auth,': cdrwa
> * /hbase/namespace/hdp_ns 'auth,': cdrwa
> * /hbase/namespace/hbase 'auth,': cdrwa
> * /hbase/hbaseid 'auth,':
> cdrwa 'world,'anyone: r
> * /hbase/table 'auth,':
> cdrwa 'world,'anyone: r
> * /hbase/table/hbase:meta 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hbase:namespace 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hdp_ns:spark_test_sink 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hdp_ns:spark_test 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hdp_ns:yhb_tbl_1 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hdp_ns:flink_test 'auth,': cdrwa
> 'world,'anyone: r
> * /hbase/table/hdp_ns:flink_test1 'auth,': cdrwa
> 'world,'anyone: r
> * /hivedelegationMETASTORE/keys/0000000019
> 'auth,': cdrwa
> * /hivedelegationMETASTORE/keys/0000000021
> 'auth,': cdrwa
> * /hivedelegationMETASTORE/keys/0000000020
> 'auth,': cdrwa
> * /hivedelegationHIVESERVER2/keys/0000000019
> 'auth,': cdrwa
> * /hivedelegationHIVESERVER2/keys/0000000021
> 'auth,': cdrwa
> * /hivedelegationHIVESERVER2/keys/0000000020
> 'auth,': cdrwa
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
