Jordan Mcmillan created KAFKA-6319:
--------------------------------------
Summary: kafka-acls regression for comma characters (and maybe
other characters as well)
Key: KAFKA-6319
URL: https://issues.apache.org/jira/browse/KAFKA-6319
Project: Kafka
Issue Type: Bug
Components: admin
Affects Versions: 1.0.0
Environment: Debian 8. Java 8. SSL clients.
Reporter: Jordan Mcmillan
As of version 1.0.0, kafka-acls.sh no longer recognizes my ACLs stored in
zookeeper. I am using SSL and the default principle builder class. My principle
name contains a comma. Ex:
"CN=myhost.mycompany.com,OU=MyOU,O=MyCompany, Inc.,ST=MyST,C=US"
The default principle builder uses the getName() function in
javax.security.auth.x500:
https://docs.oracle.com/javase/8/docs/api/javax/security/auth/x500/X500Principal.html#getName
The documentation states "The only characters in attribute values that are
escaped are those which section 2.4 of RFC 2253 states must be escaped". This
makes sense as my kakfa-authorizor log shows the comma correctly escaped with a
backslash:
INFO Principal = User:CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\,
Inc.,ST=MyST,C=US is Denied Operation = Describe from host = 1.2.3.4 on
resource = Topic:mytopic (kafka.authorizer.logger)
Here's what I get when I try to create the ACL in kafka 1.0:
{code:java}
> # kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add
> --allow-principal User:"CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\,
> Inc.,ST=MyST,C=US" --operation "Describe" --allow-host "*" --topic="mytopic"
Adding ACLs for resource `Topic:mytopic`:
User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\, Inc.,ST=MyST,C=US
has Allow permission for operations: Describe from hosts: *
Current ACLs for resource `Topic:mytopic`:
<Empty line here. I expect to see
"User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\, Inc.,ST=MyST,C=US has
Allow permission for operations: Describe from hosts: *">
{code}
Examining Zookeeper, I can see the data. Though I notice that the json string
for ACLs is not actually valid since the backslash is not escaped with a double
backslash. This was true for 0.11.0.1 as well, but was never actually a problem.
{code:java}
> # zk-shell localhost:2181
Welcome to zk-shell (1.1.1)
(CLOSED) />
(CONNECTED) /> get /kafka-acl/Topic/mytopic
{"version":1,"acls":[{"principal":"User:CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\,
Inc.,ST=MyST,C=US","permissionType":"Allow","operation":"Describe","host":"*"}]}
(CONNECTED) /> json_get /kafka-acl/Topic/mytopic acls
Path /kafka-acl/Topic/mytopic has bad JSON.
{code}
Now Kafka does not recognize any ACLs that have an escaped comma in the
principle name and all the clients are denied access. I tried searching for
anything relevant that changed between 0.11.0.1 and 1.0.0 and I noticed
KAFKA-1595:
https://github.com/apache/kafka/commit/8b14e11743360a711b2bb670cf503acc0e604602#diff-db89a14f2c85068b1f0076d52e590d05
Could the new json library be failing because the acl is not actually a valid
json string?
I can store a valid json string with an escaped backslash (ex: containing
"O=MyCompany\\, Inc."), and the comparison between the principle builder
string, and what is read from zookeeper succeeds. However, successively apply
ACLs seems to strip the backslashes and generally corrupts things:
{code:java}
> # kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add
> --allow-principal User:"CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\\\,
> Inc.,ST=MyST,C=US" --operation Describe --group="*" --allow-host "*"
> --topic="mytopic"
Adding ACLs for resource `Topic:mytopic`:
User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\\,
Inc.,ST=MyST,C=US has Allow permission for operations: Describe from hosts: *
Adding ACLs for resource `Group:*`:
User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\\,
Inc.,ST=MyST,C=US has Allow permission for operations: Describe from hosts: *
Current ACLs for resource `Topic:mytopic`:
User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\, Inc.,ST=MyST,C=US
has Allow permission for operations: Describe from hosts: *
Current ACLs for resource `Group:*`:
User:CN=CN=myhost.mycompany.com,OU=MyOU,O=MyCompany\, Inc.,ST=MyST,C=US
has Allow permission for operations: Describe from hosts: *
code}
It looks as though the backslash used for escaping RFC 2253 strings is not
being handled correctly. That's as far as I've dug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
