kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Mcmillan (JIRA)" <j...@apache.org>
Subject [jira] [Created] (KAFKA-6319) kafka-acls regression for comma characters (and maybe other characters as well)
Date Wed, 06 Dec 2017 21:47:00 GMT
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)

Mime
View raw message