FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

feat(auth): authorize query-auth reads and carry the grant on the split by plusplusjiajia · Pull Request #758 · apache/paimon-rust · GitHub

feat(auth): authorize query-auth reads and carry the grant on the split - #758

Draft
plusplusjiajia wants to merge 1 commit into
apache:mainfrom
plusplusjiajia:query-auth-carry-grant
Draft

feat(auth): authorize query-auth reads and carry the grant on the split#758
plusplusjiajia wants to merge 1 commit into
apache:mainfrom
plusplusjiajia:query-auth-carry-grant

Conversation

plusplusjiajia commented Aug 27, 2026
edited
Loading

Copy link
Copy Markdown
Member

Purpose

A query-auth.enabled table makes the server return a per-user row filter and column masking that a client is expected to apply. This client cannot apply them yet, so it refuses to read such a table at all — even for a user the server reports as unrestricted. This first slice fetches the authorization at scan-plan time and carries it to the read, so that user can read. A user with rules gets the same refusal as before.

Brief change log

Table::authorize_read asks the server once per plan, and TableScan::plan stamps the result on every split — Java wraps each split in a QueryAuthSplit for the same reason. TableRead::to_arrow then decides from the splits: each must carry a grant, obtained through this table's own handle, and unrestricted. Per split, not just the first, since split lists can be concatenated across plans.

Whether a table is query-auth is read from the server, not from the loaded handle: the option can be turned on after a table was loaded, and a cached false would skip authorization altogether. That check doubles as the first half of a freshness bracket around the auth call, which refuses a table that was re-created or evolved in the meantime, or whose identity the server no longer reports.

QueryAuthGrant keeps the response unparsed — parsing belongs with the code that applies it — and the request carries no explicit select, which the server expands to the real schema fields. Naming a reserved system column would fail its column-permission check and deny an otherwise authorized user, so a read that reaches one is refused client-side instead. A user authorized for a subset is therefore still refused, as today. AuthTableQueryResponse rejects unknown fields, unlike every other response: an absent field reads as "no rule", so a drifted protocol would otherwise look like an unrestricted grant.

Two refusals are deliberate: a restricted grant fails at planning, since a plan carries row counts and min/max that engines answer COUNT/MIN/MAX from without reading a row; and a time-travelled or branch copy is refused, since the server rules on the current schema. Only the query-auth part of ReadBuilder::new_read's gate moved to to_arrow, where the split's grant is visible; the engine-served type check stays there, since a table's declared type is known without a grant.

plusplusjiajia force-pushed the query-auth-carry-grant branch 7 times, most recently from 04e0908 to f658426 Compare August 29, 2026 15:39
plusplusjiajia force-pushed the query-auth-carry-grant branch from f658426 to adad11b Compare August 29, 2026 16:25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant


Back | FazBrowse Home | New Git URL