Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@kafka.apache.org
Date: Wed, 6 Dec 2017 21:57:00 +0000 (UTC)
From: "Ismael Juma (JIRA)" <jira@apache.org>
To: jira@kafka.apache.org
Message-ID: <JIRA.13123306.1512596773000.403002.1512597420610@Atlassian.JIRA>
In-Reply-To: <JIRA.13123306.1512596773000@Atlassian.JIRA>
References: <JIRA.13123306.1512596773000@Atlassian.JIRA> <JIRA.13123306.1512596773704@jira-lw-us.apache.org>
Subject: [jira] [Updated] (KAFKA-6319) kafka-acls regression for comma
 characters (and maybe other characters as well)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 06 Dec 2017 21:57:08 -0000


     [ https://issues.apache.org/jira/browse/KAFKA-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ismael Juma updated KAFKA-6319:
-------------------------------
    Fix Version/s: 1.1.0

> 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
>              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)