kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gustafson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-5547) Return topic authorization failed if no topic describe access
Date Thu, 03 Aug 2017 22:22:01 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113609#comment-16113609
] 

Jason Gustafson commented on KAFKA-5547:
----------------------------------------

[~huxi_2b] What we are trying to avoid is leaking information about which topics exist to
users which are not authorized. In an older version, the topic existence check came before
the authorization check, but we later fixed that so that we do both checks at the same time.
If either check failed, we return UNKNOWN_TOPIC_OR_PARTITION. My suggestion here is to check
describe access first and return TOPIC_AUTHORIZATION_FAILED on failure without even bothering
to check topic existence.

> Return topic authorization failed if no topic describe access
> -------------------------------------------------------------
>
>                 Key: KAFKA-5547
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5547
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Jason Gustafson
>              Labels: security, usability
>             Fix For: 1.0.0
>
>
> We previously made a change to several of the request APIs to return UNKNOWN_TOPIC_OR_PARTITION
if the principal does not have Describe access to the topic. The thought was to avoid leaking
information about which topics exist. The problem with this is that a client which sees this
error will just keep retrying because it is usually treated as retriable. It seems, however,
that we could return TOPIC_AUTHORIZATION_FAILED instead and still avoid leaking information
as long as we ensure that the Describe authorization check comes before the topic existence
check. This would avoid the ambiguity on the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message