You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@polaris.apache.org by "ryuan-cw (via GitHub)" <gi...@apache.org> on 2026/05/28 18:32:24 UTC

[I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

ryuan-cw opened a new issue, #4573:
URL: https://github.com/apache/polaris/issues/4573

### Is your feature request related to a problem? Please describe.

`GET /api/management/v1/catalogs` (`listCatalogs`) is authorized by `CATALOG_LIST` on the **root container** — effectively a `service_admin` capability — and it is all-or-nothing: a principal lacking that root privilege gets a hard `403`, not a filtered list. A least-privilege principal therefore cannot *discover* catalogs even for catalogs it has been explicitly granted access to.

Concretely, with a principal whose catalog role grants `CATALOG_READ_PROPERTIES` / `NAMESPACE_LIST` / `TABLE_LIST` / `TABLE_READ_DATA` on specific catalogs:

- `GET /api/management/v1/catalogs` → `403` (`Principal '…' … is not authorized for op LIST_CATALOGS`)
- `GET /api/management/v1/catalogs/{name}` (`getCatalog`) → `200`
- Iceberg catalog API (list namespaces/tables, read data) → works

So the principal can read everything in the catalogs it is granted, but cannot enumerate them. This makes the **polaris-console** catalog browser (which calls `listCatalogs`) and any read-only "viewer" persona unusable for non-admins — the catalog list is empty/forbidden.

And there is no narrower fix: `CATALOG_LIST` must sit on the root container, the only code path that places a privilege there (`PolarisAdminService.grantPrivilegeOnRootContainerToPrincipalRole`, op `ADD_ROOT_GRANT_TO_PRINCIPAL_ROLE`, itself requiring `SERVICE_MANAGE_ACCESS`) is **not exposed via the management REST API**, so the only API-reachable way to make `listCatalogs` succeed is to grant `service_admin` (full administrative access: create/drop catalogs, manage all principals/roles/grants) — the opposite of least privilege.

Relevant code (`apache-polaris-1.3.0-incubating`; authorization path unchanged on `main`):

- `PolarisAdminService.listCatalogs()` → `authorizeBasicRootOperationOrThrow(LIST_CATALOGS)`, then `listCatalogsUnsafe()` returns **all** catalogs (no filtering).
- `authorizeBasicRootOperationOrThrow(...)` resolves the **root container** as the authorization target.
- `RbacOperationSemantics`: `register(LIST_CATALOGS, CATALOG_LIST)`.
- `PolarisAuthorizerImpl`: `CATALOG_LIST` is satisfied by `SERVICE_MANAGE_ACCESS` (or catalog-level `CATALOG_READ_PROPERTIES`, etc.) **on the same securable** — i.e. on the root container, which a non-admin never holds.

### Describe the solution you'd like

When the caller does not hold `CATALOG_LIST` on the root container, `listCatalogs` should return the **subset of catalogs the caller is authorized on** (holds any catalog-role grant / `CATALOG_READ_PROPERTIES`), instead of throwing `403`. Callers with root `CATALOG_LIST` / `SERVICE_MANAGE_ACCESS` continue to see all catalogs.

This reuses the same per-securable check `getCatalog` already performs, mirrors how `listNamespaces` / `listTables` are scoped within a catalog, and matches how object stores filter list results by ACL. Because each catalog is itself a securable with grants (unlike principal-roles in #363), filtering the catalog list by the caller's effective grants is straightforward. Result: non-admins discover exactly the catalogs they can use, the console works for read-only personas, and no `service_admin` grant or root-container grant API is required.

### Describe alternatives you've considered

- **Expose root-container grants via REST** so `CATALOG_LIST`-only can be granted to a principal role — enables a "list, no write/drop" role, but is still all-or-nothing ("see all catalogs") and adds a privilege that is hard to reason about; filtering is more useful and least-surprising.
- **`service_admin`** (current workaround) — over-privileged (can drop catalogs, manage all principals); unacceptable for viewer / least-privilege use.
- **A catalog-scoped discovery endpoint** — cumbersome when a principal has access to many catalogs (also noted in #363).

### Additional context

Sibling issue #363 raises the same class of problem for `listPrincipalRoles` under `catalog_admin`. Performance: filtering adds a per-catalog authorization check; catalog counts are typically small and this can be batched if needed. Observed on Apache Polaris 1.3.0-incubating via polaris-console; authorization path verified unchanged on `main`.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.

github-actions[bot] commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-4899463724

   This issue is stale because it has been open 30 days with no activity. Remove stale label or comment if you think it's still relevant.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "venkateshwaracholan (via GitHub)" <gi...@apache.org>.

venkateshwaracholan commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-4577968066

   
   I checked the current implementation on main.
   
   listCatalogs() is authorized via LIST_CATALOGS, which maps to the root-level CATALOG_LIST privilege. The same authorization requirement is reflected in PolarisAdminServiceAuthzTest.testListCatalogsPrivileges and in the CLI docs.
   
   That said, I can see the usability issue described here. A user may be able to access a catalog directly via getCatalog() and perform operations within that catalog, but still be unable to call listCatalogs() because they don't have the root-level privilege.
   
   Would it make sense for listCatalogs() to return only the catalogs a caller can already access, while preserving the current behavior for users that have CATALOG_LIST?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "dttung-starling (via GitHub)" <gi...@apache.org>.

dttung-starling commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-5573955436

   👍 on this issue. In my current place, we use Polaris with [polaris-console](https://github.com/apache/polaris-tools/tree/main/console) and want to give a user read-only access to browse catalogs there. LIST_CATALOGS can't be granted to anything short of service_admin, so a least-privilege "viewer" role can't use the console catalog browser at all


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "flyrain (via GitHub)" <gi...@apache.org>.

flyrain commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-4636336909

   The proposed behavior makes sense. Returning a list of catalogs only a caller can access feels more aligned with least privilege and with how most users would expect catalog discovery to work.
   
   Implementation wise, it doesn't seem particularly difficult either. The existing admin behavior could remain unchanged, while non admin callers receive a filtered list based on catalog level authorization checks similar to those already performed by getCatalog(). To me, the bigger question is agreeing on the API semantics rather than the implementation itself. I'm supportive on the change.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "dimas-b (via GitHub)" <gi...@apache.org>.

dimas-b commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-4581425620

   This issue looks very relevant. Thanks @ryuan-cw and @venkateshwaracholan for filing and raising good points!
   
   There was a related `dev` discussion: https://lists.apache.org/thread/w58zrjt6jpq33mv9lvqzndqc6no5l7xb 
   
   Let's continue that email thread for discussing specific authZ and filtering changes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [FEATURE REQUEST] listCatalogs should return the catalogs a caller can access, instead of requiring service-admin (CATALOG_LIST on root) [polaris]

Posted by "dennishuo (via GitHub)" <gi...@apache.org>.

dennishuo commented on issue #4573:
URL: https://github.com/apache/polaris/issues/4573#issuecomment-6461541668

   @ryuan-cw @dttung-starling Some emerging use cases are causing me to explore a slightly different formulation of how to fix this -- adding a *data-plane-facing* version of catalog listing, called something like `listAccessibleCatalogs` that would sit under the `/api/catalog` path rather than `/api/management`; mailing-list discussion here https://lists.apache.org/thread.html/5w2dk760omggpzpz9pwylhb1wtlqf9rv and draft PR here: https://github.com/apache/polaris/pull/5891
   
   Following the principle of least privilege, this goes beyond "read-only", since `CATALOG_READ_PROPERTIES` also contains more sensitive properties that an *admin* might need to know, but a *catalog-user* doesn't need to know, such as `StorageConfiguration` or for federated catalogs, `ConnectionConfiguration`.
   
   For your use cases, did you want the more restricted list for *data-plane* use cases that would be satisfied by a very pruned set of properties (initially, *only* the catalog-name in the returned lists), or did your use cases actually want the pruned *admin* view of catalogs?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org