[
https://issues.apache.org/jira/browse/KAFKA-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Mcmillan updated KAFKA-6319:
-----------------------------------
Description:
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.
was:
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.
> 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)
