jiangxt2 commented on PR #12786: URL: https://github.com/apache/gravitino/pull/12786#issuecomment-5505909991
> This change break the Gravitino privilege semantics. > > SELECT_TABLE and MODIFY_TABLE isn't related. Deny MODIFY_TABLE won't influence SELECT_TABLE. Thanks for review. I agree that SELECT_TABLE and MODIFY_TABLE are independent. This PR changes only one specific result: for an explicit loadTable(..., privileges=MODIFY_TABLE) request where MODIFY_TABLE is denied but SELECT_TABLE or PROBE_TABLE_LIKE is allowed, a missing table currently yields 404 after an existence probe; the patch returns 403 without probing. I should have made that explicit. This is the Spark 3.5 connector's write-aware load path. Once the requested MODIFY_TABLE authorization fails, the write cannot proceed. The subsequent allowCheckExistence probe changes only the error classification, not the authorization outcome. For an external JDBC catalog, however, tableExists() may open a backend connection, and a connection failure can mask the original denial with an internal error. Ordinary loadTable behavior remains unchanged: a caller with SELECT_TABLE can still load an existing table and receives 404 for a missing table, while ordinary denied-load probes also retain their current behavior. Could you confirm whether Gravitino intends to preserve that SELECT_TABLE- or PROBE_TABLE_LIKE-authorized 404 classification even after an explicitly requested MODIFY_TABLE authorization has failed? If so, I agree that this PR conflicts with the intended semantics and that the zero-I/O requirement cannot be implemented this way. Otherwise, I can add a regression test using the same principal with ALLOW SELECT_TABLE and DENY MODIFY_TABLE, showing that normal reads remain intact while the denied write-aware load performs no existence probe. If a client depends on that exact 404 outcome, please point me to the relevant flow so I can account for it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
