Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
We have historically had logic in the api layer to avoid leaking the existence or non-existence of topics to clients which are not authorized to describe them. The way we have done this is to always authorize the topic name first before checking existence.
Topic ids make this more difficult because the resource (ie the topic name) has to be derived. This means we have to check existence of the topic first. If the topic does not exist, then our hands are tied and we have to return UNKNOWN_TOPIC_ID. If the topic does exist, then we need to check if the client is authorized to describe it. The question comes then what we should do if the client is not authorized?
The current behavior is to return UNKNOWN_TOPIC_ID. The downside is that this is misleading and forces the client to retry even though they are doomed to hit the same error. However, the client should generally handle this by requesting Metadata using the topic name that they are interested in, which would give them a chance to see the topic authorization error. Basically the fact that you need describe permission in the first place to discover the topic id makes this an unlikely scenario.
There is an argument to be made for TOPIC_AUTHORIZATION_FAILED as well. Basically we could take the stance that we do not care about leaking the existence of topic IDs since they do not reveal anything about the underlying topic. Additionally, there is little likelihood of a user discovering a valid UUID by accident or even through brute force. The benefit of this is that users get a clear error for cases where a topic Id may have been discovered through some external means. For example, an administrator finds a topic ID in the logging and attempts to delete it using the new `deleteTopicsWithIds` Admin API.
Attachments
Issue Links
- links to