Hi Jingsong, +1 from me.
I support introducing a language-neutral permission management contract for the REST Catalog ecosystem. Keeping it scoped to `RESTCatalog` looks like a reasonable initial boundary, and the proposed APIs and Spark procedures seem like a practical starting point. Thanks for driving this discussion and preparing the POC. Best, Yijie Shao Jiajia Li <[email protected]> 于2026年8月24日周一 18:46写道： > Hi Jingsong, > +1 for defining this contract as part of the REST Catalog ecosystem. We > run a production Paimon REST Catalog server and very much need a neutral > permission management contract like this — it is exactly what engine > integrations and tools need as well. The proposed model and boundaries look > right to me. > Best, > Jiajia > ------------------------------------------------------------------ > From:Jingsong Li <[email protected]> > Send Time:Mon, Aug 24, 2026, 18:21 > To:dev<[email protected]> > Subject:[DISCUSS] Introduce REST permission management APIs > Hi community, > I'd like to discuss introducing a language-neutral permission > management contract for Paimon's REST Catalog support. > RESTCatalog is becoming the common catalog interface across engines > and services. Authentication and authorization decisions should remain > responsibilities of the REST server, but clients still need an > interoperable way to list, grant, and revoke permissions without > depending on a vendor-specific SDK. > I prepared a POC in the following draft PR: > https://github.com/apache/paimon/pull/9377 < > https://github.com/apache/paimon/pull/9377 > > The current proposal has the following boundaries: > - Add a small PermissionManagement contract with list, grant, and > revoke operations. > - Expose PermissionManagement directly from RESTCatalog instead of > changing the generic Catalog interface. Other catalog implementations > are therefore not required to support it. > - Make the corresponding RESTApi methods public so Java clients and > engine integrations can use the same transport contract. > - Define a separate rest-management-open-api.yaml with these endpoints: > - GET /v1/catalogs/{catalog}/permissions > - POST /v1/catalogs/{catalog}/permissions/grant > - POST /v1/catalogs/{catalog}/permissions/revoke > - Use a flat resource-oriented permission model covering catalog, > database, table, view, function, column, row filter, and column > masking permissions, with optional expiration. > - Keep user and role lifecycle, authentication, policy persistence, > and authorization enforcement outside this API and under the > responsibility of the REST server implementation. > - Initially expose the capability to Spark SQL through > grant_permission, list_permissions, and revoke_permission procedures. > Future GRANT/REVOKE SQL syntax could be layered on the same Java and > REST contracts without changing the server API. > I would appreciate feedback on the following questions: > 1. Should Paimon define this permission management contract as part of > its REST Catalog ecosystem? > 2. Is exposing it only through RESTCatalog the right initial boundary, > or should it be modeled as a generic Catalog capability? > 3. Should the management OpenAPI contract remain separate from > rest-catalog-open-api.yaml? > 4. Are the proposed resource model and endpoint shapes suitable for > different REST Catalog server implementations? > 5. Are Spark procedures a reasonable first SQL integration, while > leaving dedicated permission SQL syntax for a follow-up? > The PR is intended as a POC for discussion, and I am happy to adjust > the design based on community feedback. > Best, > Jingsong >
