Thanks for the proposal. Enabling privilege aware listing is the right direction.
Per entity authorization does introduce performance concerns, but I do not see this as a blocker, and I don't consider batching authZ solves all problems given that the number of entities is not bounded. Instead, it makes more sense to tie list filtering with pagination, which provides a natural bound on the amount of authorization work performed per request. With filtering enabled, the overhead scales with page size and remains predictable and tunable by deployment. For this reason, it makes more sense to require filtering to be used only with paginated list operations, so the authorization cost stays bounded. This is consistent with existing catalog services such as AWS Glue and Databricks Unity Catalog, which rely on mandatory pagination and the ways of permission check vary based on use cases. Page size effectively becomes the tuning mechanism for balancing latency and throughput. Deployments with high latency authorizers may reasonably choose to reduce page size, disable filtering, or rely on authorizer side batching or caching to mitigate the overhead. Yufei On Tue, Jan 13, 2026 at 5:08 PM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > >
