Hi Jingsong, Thanks for driving this. +1 on the overall direction.
A few thoughts on the design: - Keep the first version flat and simple. - Leave room to extend resource fields in the future. - Keep the management API separate from the core catalog API. - It may also be worth considering behaviors such as owner permission and grant option in the detailed design. The proposed REST APIs and Spark procedures look like a good starting point. Best, Dapeng yijie shao <[email protected]> 于2026年8月24日周一 18:53写道： > 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 > > >
