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
