[jira] [Created] (KAFKA-6319) kafka-acls regression for comma characters (and maybe other characters as well)

["Jordan Mcmillan (JIRA)" <ji...@apache.org>]

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)