[
https://issues.apache.org/jira/browse/KAFKA-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15282659#comment-15282659
]
Edoardo Comar commented on KAFKA-3396:
--------------------------------------
Hi [~granthenke] I thought that if a user has DESCRIBE permission on topic yet
to be created,
autocreate is on, but the user has no CREATE permission on cluster,
there is no reason to hide the name of the topic or hide the reason of the
failure.
The fact that, in SimpleAclAuthorizer, the DESCRIBE permission only accepts the
name of the topic or a wildcard for all topic,
makes this scenario not very likely, IMHO, but still a possibility.
Might be more common with an Authorizer implementation that allows topic names
with wildcard
(e.g. I could have DESCRIBE on all topics starting named like "edo-*")
have to work on unit tests before I can make a PR
> Unauthorized topics are returned to the user
> --------------------------------------------
>
> Key: KAFKA-3396
> URL: https://issues.apache.org/jira/browse/KAFKA-3396
> Project: Kafka
> Issue Type: Bug
> Reporter: Grant Henke
>
> Kafka's clients and protocol exposes unauthorized topics to the end user.
> This is often considered a security hole. To some, the topic name is
> considered sensitive information. Those that do not consider the name
> sensitive, still consider it more information that allows a user to try and
> circumvent security. Instead, if a user does not have access to the topic,
> the servers should act as if the topic does not exist.
> To solve this some of the changes could include:
> - The broker should not return a TOPIC_AUTHORIZATION(29) error for
> requests (metadata, produce, fetch, etc) that include a topic that the user
> does not have DESCRIBE access to.
> - A user should not receive a TopicAuthorizationException when they do
> not have DESCRIBE access to a topic or the cluster.
> - The client should not maintain and expose a list of unauthorized
> topics in org.apache.kafka.common.Cluster.
> Other changes may be required that are not listed here. Further analysis is
> needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
