leaves12138 commented on code in PR #9872:
URL: https://github.com/apache/paimon/pull/9872#discussion_r4022185643
##########
paimon-core/src/main/java/org/apache/paimon/table/source/AbstractDataTableScan.java:
##########
@@ -383,34 +385,24 @@ private void ensureFilterPushdown() {
}
/**
- * Push the auth-widened read type to the snapshot reader before planning,
so file-level column
- * pruning keeps the files of the columns the rules read.
+ * Push the read type expanded for filters and auth rules to the snapshot
reader before
+ * planning, so file-level column pruning keeps their dependencies.
*/
private void applyAuthReadType(@Nullable TableQueryAuthResult
queryAuthResult) {
if (readType == null) {
return;
}
- RowType desired = readType;
- if (queryAuthResult != null && queryAuthResult.hasRules()) {
- // post-mask conjuncts are evaluated at read time; their columns
must survive planning
- RowType widened =
- TableQueryAuthResult.appendMissingFields(
- schema.logicalRowType(),
- readType,
-
queryAuthResult.authFields(readType.getFieldNames(), userFilter));
- if (widened != null) {
- desired = widened;
- }
- }
- // never narrow within this scan's lifetime: readers fix their schema
on first use
- RowType widenedToApplied =
- TableQueryAuthResult.appendMissingFields(
+ RowType desired =
+ TypeUtils.withMissingFields(
+ schema.logicalRowType(),
+ readType,
+ ReadTransform.requiredFields(readType, userFilter,
queryAuthResult));
Review Comment:
[P1] Authorize user-filter operands before widening the read schema
This adds `userFilter` operands to the physical read after `authQuery()` has
authorized only `readType.getFieldNames()` (lines 283-284). `ReadTransform`
then evaluates those additional columns, although the catalog never authorized
the caller to read them.
Reproduced with the existing REST test server: create an auth-enabled table
`(public_id INT, secret_score INT)` containing `(1,10), (2,20), (3,30)`, and
grant column access only to `public_id`. Projecting `secret_score` correctly
throws "has no permission", but `withProjection(new int[] {0})`, a predicate
`secret_score = 20`, and `newRead().executeFilter()` successfully return `[2]`.
Repeated predicates can therefore probe values in the restricted column without
column permission.
Please authorize the union of requested output columns and **user-query
predicate operands** before planning/reading, rather than adding those operands
only after authorization. Trusted row-filter/mask dependencies are a separate
concern. Add a REST regression with column-scoped permissions; locally,
including the predicate operands in the authorization request makes this
regression reject the query as expected.
--
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]
