You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@paimon.apache.org by Jingsong Li <ji...@gmail.com> on 2026/08/24 10:21:31 UTC
[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
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
Re: [DISCUSS] Introduce REST permission management APIs
Posted by Arnav Balyan <ar...@gmail.com>.
Hi Jingsong, thanks a lot, that makes sense!
Warm Regards,
Arnav
On Mon, Aug 24, 2026 at 6:12 PM Jingsong Li <ji...@gmail.com> wrote:
> Thanks all for your feedback.
>
> Hi Arnav, The current convention for the REST server implementation is
> to throw a `NotImplementedException` if a specific method has not been
> implemented. I believe this is something users can clearly accept.
>
> Best,
> Jingsong
>
> On Mon, Aug 24, 2026 at 7:32 PM Arnav Balyan <ar...@gmail.com>
> wrote:
> >
> > 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 <sd...@apache.org> 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 <sh...@gmail.com> 于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 <pl...@alibaba-inc.com> 于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 <ji...@gmail.com>
> > > > > Send Time:Mon, Aug 24, 2026, 18:21
> > > > > To:dev<de...@paimon.apache.org>
> > > > > 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
> > > > >
> > > >
> > >
>
Re: [DISCUSS] Introduce REST permission management APIs
Posted by Jingsong Li <ji...@gmail.com>.
Thanks all for your feedback.
Hi Arnav, The current convention for the REST server implementation is
to throw a `NotImplementedException` if a specific method has not been
implemented. I believe this is something users can clearly accept.
Best,
Jingsong
On Mon, Aug 24, 2026 at 7:32 PM Arnav Balyan <ar...@gmail.com> wrote:
>
> 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 <sd...@apache.org> 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 <sh...@gmail.com> 于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 <pl...@alibaba-inc.com> 于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 <ji...@gmail.com>
> > > > Send Time:Mon, Aug 24, 2026, 18:21
> > > > To:dev<de...@paimon.apache.org>
> > > > 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
> > > >
> > >
> >
Re: [DISCUSS] Introduce REST permission management APIs
Posted by Arnav Balyan <ar...@gmail.com>.
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 <sd...@apache.org> 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 <sh...@gmail.com> 于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 <pl...@alibaba-inc.com> 于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 <ji...@gmail.com>
> > > Send Time:Mon, Aug 24, 2026, 18:21
> > > To:dev<de...@paimon.apache.org>
> > > 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
> > >
> >
>
Re: [DISCUSS] Introduce REST permission management APIs
Posted by Dapeng Sun <sd...@apache.org>.
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 <sh...@gmail.com> 于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 <pl...@alibaba-inc.com> 于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 <ji...@gmail.com>
> > Send Time:Mon, Aug 24, 2026, 18:21
> > To:dev<de...@paimon.apache.org>
> > 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
> >
>
Re: [DISCUSS] Introduce REST permission management APIs
Posted by yijie shao <sh...@gmail.com>.
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 <pl...@alibaba-inc.com> 于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 <ji...@gmail.com>
> Send Time:Mon, Aug 24, 2026, 18:21
> To:dev<de...@paimon.apache.org>
> 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
>
Re: [DISCUSS] Introduce REST permission management APIs
Posted by Jiajia Li <pl...@alibaba-inc.com>.
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 <ji...@gmail.com>
Send Time:Mon, Aug 24, 2026, 18:21
To:dev<de...@paimon.apache.org>
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