You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Rajini Sivaram (JIRA)" <ji...@apache.org> on 2017/12/07 09:03:00 UTC
[jira] [Assigned] (KAFKA-6319) kafka-acls regression for comma
characters (and maybe other characters as well)
[ https://issues.apache.org/jira/browse/KAFKA-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajini Sivaram reassigned KAFKA-6319:
-------------------------------------
Assignee: Rajini Sivaram
> 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
> Assignee: Rajini Sivaram
> Labels: regression
> Fix For: 1.1.0
>
>
> 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)