Hi Jingsong, Thank you for raising this thread, having a unified security layer would be incredibly helpful for clients attempting to standardize permission management and allow organizations to implement their own governance and compliance.
My thoughts on the proposal are: 1. I support defining this contract as part of rest catalog. Standardizing the transport would allow the clients to avoid vendor specific SDKs. 2. Exposing this capability through the rest catalog can keep policies unified across individual catalogs and may help avoid maintenance overhead. 3. I support keeping it as an OpenAPI contract to allow a clear distinction between catalog operations vs admin operations. 4. To maintain interoperability, maybe the spec could define a `supportedCapabilities` to indicate the server specific capabilities to map the endpoint shapes to the proposed model. 5. I support having Spark procedures as a reasonable SQL integration. Thank you for initiating this discussion and this new direction. I would be happy to support with testing/implementation. Warm Regards, Arnav On Mon, Aug 24, 2026 at 4:42 PM Dapeng Sun <[email protected]> wrote: > 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 > > > > > >
