JingsongLi commented on code in PR #758:
URL: https://github.com/apache/paimon-rust/pull/758#discussion_r3893629966
##########
crates/paimon/src/table/table_read.rs:
##########
@@ -712,12 +737,68 @@ impl<'a> PaimonTableRead<'a> {
reader.read(splits)
}
+ /// Allowed only if the splits carry a grant saying the server imposed
+ /// nothing. Never fetched here, so a split without one fails closed.
+ fn ensure_authorized_by_splits(
+ &self,
+ core_options: &CoreOptions,
+ data_splits: &[DataSplit],
+ ) -> crate::Result<()> {
+ // Unconditional: unrelated to query-auth.
+
core_options.ensure_type_paimon_served(&self.table.identifier().full_name())?;
+ // The handle's flag is a snapshot; the marker survives a round-trip.
+ let required = core_options.query_auth_enabled()
+ || data_splits.iter().any(|s| s.query_auth_required());
Review Comment:
[P1] Do not accept an unmarked split from a stale REST handle
When a REST handle was loaded while query auth was false,
`core_options.query_auth_enabled()` stays false. If the server later enables
restricted query auth, a caller that bypasses `TableScan` can still pass an old
unmarked plan—or a split made through the public `DataSplitBuilder`—to this
synchronous `to_arrow` boundary. `required` is false, so the method returns
rows without any auth RPC or grant. This contradicts the PR’s stated
stale-handle guarantee; the new test covers planning after the toggle, but not
this public read path.
Please make REST reads require evidence that the split was planned after a
live server-state check even when that check said query auth was disabled (for
example, a catalog-session-bound checked-plan capability distinct from
`query_auth_required`), or make materialization able to re-authorize. Unmarked
splits should remain acceptable only where no REST authorization boundary
exists. Add a regression for: load with false, retain/build an unmarked split,
enable a restricted response, then call `to_arrow` and require refusal.
--
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]
