You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/12/07 20:31:00 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16282489#comment-16282489 ]
ASF GitHub Bot commented on KAFKA-6319:
---------------------------------------
GitHub user rajinisivaram opened a pull request:
https://github.com/apache/kafka/pull/4303
KAFKA-6319: Quote strings stored in JSON configs
This is required for ACLs where SSL principals contain special characters (e.g. comma) that are escaped using backslash. The strings need to be quoted for JSON to ensure that the JSON stored in ZK is valid.
Also converted `SslEndToEndAuthorizationTest` to use a principal with special characters to ensure that this path is tested.
*More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.*
*Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.*
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rajinisivaram/kafka KAFKA-6319
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/4303.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4303
----
commit 9518f465a76b3431a36777d83d57bf1430eaa302
Author: Rajini Sivaram <ra...@googlemail.com>
Date: 2017-12-07T20:00:03Z
KAFKA-6319: Quote strings in JSON to enable ACLs for principals with special chars
----
> 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)