Hi Grace, It definitely makes sense to enhance Polaris to provide authorization protection for listing individual entities. So thanks a lot for starting this discussion!
As Robert noted, practical aspects of implementing this right now may be challenging and require substantial refactorings. Please do not consider this as discouragement, though :) If you have some specific code changes in mind, please feel free to share them as a PR and we can see how to make incremental progress. Are you thinking of making an end-to-end solution using the Polaris native RBAC or something like OPA? I'd also propose to discuss this in the next Community Sync meeting [1] [1] https://groups.google.com/g/polaris-community-sync Cheers, Dmitri. On Mon, Jan 12, 2026 at 5: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 >
