1. If we don't pass any write privilege, it means that we need a select privilege. 2. If someone else have implemented his catalog store and custom catalog, he can use new version Flink without modification. If we don't provide the fallback implementation, he need to implement the new method, and compile the new package (Because I modified other code and use the new method, you can see https://github.com/apache/flink/pull/27389/changes#diff-bc36a98ec4036876100d841f5f24bbcd2ab7915158d55e131e8e66f971154f05). Usually, access control is disabled by default. It should be enabled when access control is required. If someone require the access control, he should implement the new method.
Leonard Xu <[email protected]> 于2026年2月10日周二 15:28写道： > Hi Rory, > Thanks for the proposal. Two quick questions: > (1) The motivation of this FLIP is to distinguish the access types of read > and write, but it only offers a TableWritePrivilege interface. Where is the > read part? > (2) Regarding the trade-off between access control and backward > compatibility, current proposed fallback implementation may cause users to > skip access control. Since this is a newly added method, I don't understand > why we need a fallback implementation for backward compatibility. > Best, > Leonard > > > 2026 2月 10 14:29，roryqi <[email protected]> 写道： > > > > Thanks for your reply. > > 1. I added code in the section `Public Interfaces`. Thanks for your > guidance. > > 2. Actually other systems may implement a custom CatalogManager. So it > > would be better to keep compatible. > > 3. I got your point. After thinking, I feel I should change the > > description of the insert privilege. It should be ` The privilege > > of adding rows to the non-CDC table or writing data changes to the CDC > > table`. WDYT? > > > > Xuyang <[email protected]> 于2026年2月10日周二 10:28写道： > >> > >> Thanks for driving this. Overall it looks good to me, and I have some > minor comments below: > >> 1. Please refer to other FLIPs and list the code changes to the public > API in the "Public Interfaces" section. > >> 2. CatalogManager is an internal API, and can we directly modify the > existing getTable method? > >> 3. For CDC write scenarios, setting TableWritePrivilege to INSERT feels > a bit odd IMO, especially given its description "/** The privilege of > adding rows to the table. */". Curious to hear others’ thoughts. > >> > >> > >> > >> > >> > >> -- > >> > >> Best！ > >> Xuyang > >> > >> > >> > >> At 2026-02-09 23:39:09, "roryqi" <[email protected]> wrote: > >>> Hi Flink Community, > >>> > >>> I'd like to propose an enhancement to the Catalog interface to better > >>> support access control scenarios. > >>> > >>> Problem Statement > >>> > >>> For custom catalogs that implement access control, read and write > >>> permissions often need to be distinguished. Currently, Flink always > invokes > >>> Catalog#getTableto look up tables, regardless of whether the operation > is > >>> for reading or writing. This limitation makes it challenging for > catalogs > >>> to enforce proper write-level access control. > >>> > >>> Proposed Solution > >>> > >>> I've submitted a PR that adds a new variant of getTable method which > >>> explicitly indicates when write privileges are required. Key aspects of > >>> this implementation: > >>> > >>> Backward Compatibility: The new method includes a default > implementation > >>> that calls the existing getTable, ensuring no breaking changes > >>> > >>> Write Operation Coverage: All write operations (INSERT, UPDATE, DELETE, > >>> etc.) will use this new method for table lookup > >>> > >>> Industry Validation: This approach aligns with Apache Spark's similar > >>> interface enhancement (see https://github.com/apache/spark/pull/47772) > >>> > >>> Reference Materials > >>> > >>> FLIP Link: > >>> > https://docs.google.com/document/d/1wf7PGYURa8jH69ISU-xV7HNctaWViZw3t9sy-niuAbI/edit?tab=t.0 > >>> > >>> JIRA Issue: https://issues.apache.org/jira/browse/FLINK-38848 > >>> > >>> Pull Request: https://github.com/apache/flink/pull/27389 > >>> > >>> Previous discussion thread: > >>> https://lists.apache.org/thread/gfq316x9vrdwmgpw0hx4r7gpc0qkgvk1 > >>> > >>> This enhancement would significantly improve catalog implementations' > >>> ability to enforce fine-grained access control, particularly important > in > >>> multi-tenant environments. I'm happy to start a discussion on the dev > >>> mailing list if that would be more appropriate for this type of > interface > >>> change. > >>> > >>> Looking forward to the community's feedback on this discussion > >>> > >>> Best > >>> > >>> Rory > >
