morningman opened a new pull request, #66770:
URL: https://github.com/apache/doris/pull/66770
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary:
Deciding what a user may access is wired into `fe-core`.
`CatalogAccessController` is an `fe-core`
interface with one method per kind of object, the two Ranger integrations
implement it from inside
the kernel, and the row-filter / data-mask payloads handed to the planner
are kernel classes.
Anything outside this repository that wants to decide access has to be
compiled against `fe-core`
internals, and the Ranger sources ship inside `fe-core.jar` whether a
deployment uses them or not.
This PR turns "who decides access" into a plugin contract, and makes both
the built-in `GRANT` model
and the Ranger sources implementations of that contract.
**New modules**
- `fe-authorization-api` — a neutral vocabulary with no `fe-core` types:
actions, requirements
("any of these" / "all of these"), the resources that can be asked about,
subjects, and the
row-filter / data-mask payloads.
- `fe-authorization-spi` — the contract itself: check a requirement, check
one action, ask for row
filters, ask for column masks, plus a lifecycle and an
`AuthorizationContext` carrying the
questions a decision needs (the roles of a subject; whether the
instance-wide source has already
granted it).
- `fe-authorization-plugins/{ranger-common,ranger-doris,ranger-hive}` — the
Ranger sources, now
outside the kernel and shipped as installable plugins.
**What changed in the engine**
- Every access check now goes through one decision point.
`AccessControllerManager` keeps only the
routing — a table from resource kind to the source governing it — and
converts a refusal back into
the boolean its existing callers expect.
- The manager no longer computes a global verdict of its own and no longer
ORs two sources' answers
together. Each source now grants or refuses its own exemptions, which is
what makes the policy in
force on an object readable from the configuration rather than from two
places at once.
- A refusal is thrown and carries its reason, instead of being a boolean
that drops it.
- The Ranger plugins are loaded by the same machinery the other plugin
families already use: an API
version gate, a child-first class loader, a per-plugin directory under
`plugins/authorization/`,
and registration in `information_schema.extensions`.
**Compatibility**
- `access_controller.class` keeps accepting the class names it accepted
before. The one name that
moved out of the kernel is mapped by an alias table inside the kernel, and
a third-party
controller still implementing the old interface keeps working through an
adapter (the old
interface is deprecated, not removed).
- `access_controller_type` is unchanged; its accepted values are the same.
- A third-party controller that implemented **column masking or row
filtering** must be recompiled:
the four payload classes it used were replaced by neutral ones. Erasure
hides this at class-load
time, so it would otherwise surface as `NoClassDefFoundError` during
execution.
### Release note
Authorization sources are now plugins.
- The Ranger integrations (`ranger-doris`, `ranger-hive`) are no longer part
of `fe-core.jar`. The
release installs them under `plugins/authorization/`, and an upgraded
deployment must carry that
directory over — a deployment that does not will start normally and fail
on the first statement
that reaches the affected catalog. `information_schema.extensions` now
reports both with
`SOURCE = EXTERNAL` instead of `BUILTIN`.
- The `ranger-hive` audit flush timer no longer appears in the
`doris_fe_thread_pool` metrics; a
plugin cannot register into the FE's thread-pool registry.
- A third-party access controller that implements column masking or row
filtering must be
recompiled against the new payload types.
### Check List (For Author)
- Test
- [ ] Regression test
- [x] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason
The change is meant to keep every access decision identical, so the main
evidence is a golden
matrix rather than new assertions: `AccessControlBehaviorBaselineTest`
records the answer for
every combination of default source (built-in / Ranger) × catalog
(internal / plain external /
Ranger-governed) × user (global admin, global node, table-level grantee,
Ranger-only grantee, no
grants) × all 17 `PrivPredicate` constants × probe point (catalog,
database, table, columns, row
filters, column masks, resources, workload groups, storage vaults). It
stayed byte-for-byte
unchanged across all of the commits here. Alongside it: an end-to-end test
that starts an FE on an
authorization plugin installed from a directory and shows the plugin's
refusal is what the user
gets, a frozen interface surface for the api and spi modules, and the
tests of the classes
touched (~480 tests) run as a set at each step.
Ranger's own regression suite (`regression-test/suites/ranger_p2`) needs a
live Ranger server and
has not been run for this PR.
- Behavior changed:
- [ ] No.
- [x] Yes. See the release note above: where the Ranger sources are
installed from, their
`SOURCE` in `information_schema.extensions`, one thread-pool metric,
and the recompilation a
third-party controller with data policies needs.
- Does this need documentation?
- [ ] No.
- [x] Yes. Installing an authorization plugin and writing one are both
new surface; a
documentation PR will follow. `fe-authorization-spi/README.md` carries
a worked example in the
meantime.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
