plusplusjiajia commented on code in PR #758:
URL: https://github.com/apache/paimon-rust/pull/758#discussion_r3906430875
##########
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:
@JingsongLi The gap is real, but I could not find a fix worth its cost, so
I documented it here and in the PR description.
I implemented your suggestion first. It broke four legitimate flows on
ordinary, non-query-auth REST tables — including DataFusion's
register_cow_target_table and the documented C paimon_plan_from_split_bytes
round trip — because it required enumerating every path that rebuilds a planned
split, and I missed several. It also proved nothing: DataSplit is publicly
serde-serializable, so {query_auth_checked: true, query_auth_required: false}
skips both /auth and grant validation.
And closing it buys little: Table::file_io() and
DataSplit::data_file_path() are public, so the same caller can read the bytes
without touching TableRead. A real boundary means binding data tokens to an
authorization epoch at the data plane — server-side work not available to us.
Java stops here too.
So the contract is plan-time: callers must re-plan after an authorization
change. A split from a query-auth table still fails closed if it lost its grant.
Do you have a better idea?
--
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]
