Thanks Grace for the proposal! Yes, Polaris doesn't "respect" the caller's privileges on the listed entities. I think that catalogs should, as you propose, not yield entries to which the caller does not have (any) access to. Not yielding inaccessible entries is both a convenience but IMO more importantly does not yield _potentially_ sensitive information. I definitely support the idea to perform access checks on the listed entities. I'd also support the idea to change the default behavior to not return inaccessible entries, potentially in a major version bump.
The practical side however is somewhat more effort, because the current code does not support batch access checks. There's an ongoing effort to improve the authorization parts of Polaris, so it might be premature to discuss the necessary refactorings and code changes and details at this time. But it's definitely the right time to gather consensus on the functionality! Robert On Mon, Jan 12, 2026 at 11:15 PM Zhiyang Chen <[email protected]> wrote: > > Hi everyone, > > I'd like to propose a change on how Polairs handles authorization for list > operations (LIST_CATALOGS, LIST_NAMESPACES, LIST_TABLES). > > Today, Polaris checks if a user has LIST_* privilege on the parent entity, it > doesn’t filter which child entities the user has access to. For example, if a > user has LIST_TABLES privilege on the namespace, all the tables will return, > regardless of the tables that user has access to. > > This leads to two issues: > 1. Discoverability: a user may have access to one or more entities (such as > tables) within a namespace, but not have the namespace-level LIST_* > privilege. In this case, the user cannot list or discover any of the entities > they are allowed to access. > > 2. Visibility of Unauthorized Entities: a user may have LIST_* privileges on > a parent entity but not have access to all the child entities within it. In > this case, list operations return entities the user is not authorized to > access, exposing unauthorized entity names and metadata. > > The proposal adds optional entity-level filtering at the PolarisAuthorizer > layer so that list results better reflect the access permissions. Existing > behavior would remain available and filtering would be opt-in. > > Attaching the short design doc with details: > https://docs.google.com/document/d/1PyIISgK2FVK0m8t4104KZpKAWb4d1Wy0UhZQzut4pIc/edit?usp=sharing, > would like to hear your thoughts on this. > > Thanks, > Grace
