raghav-reglobe opened a new pull request, #70371:
URL: https://github.com/apache/doris/pull/70371
### What problem does this PR solve?
Issue Number: None (reported privately to the maintainers; see the
discussion there)
Related PR: None
Problem Summary:
A direct `GRANT` requires the grantor to hold `grant_priv` together with
every privilege it hands out on that object
(`GrantTablePrivilegeCommand.checkTablePrivileges` rule 4 and the resource /
workload-group equivalents). Granting a **role** hands out everything the role
carries, but `GrantRoleCommand` and the `DEFAULT ROLE` of `CREATE USER` were
gated on `grant_priv` alone, so an account holding `grant_priv` and nothing
else could take any existing role for itself or hand it to another account.
Changing **another account's credentials** — `ALTER USER ... IDENTIFIED BY`,
an authentication binding, and `SET PASSWORD FOR` — was gated on `grant_priv`
as well, although it amounts to taking that account over.
Fix:
- `GRANT role` and `CREATE USER ... DEFAULT ROLE` are held to the rule a
direct grant already enforces: the grantor needs `grant_priv` plus every
privilege the role carries on the same object, checked object by object over
the role's table, column, resource, cloud cluster / stage, storage-vault and
workload-group privileges. `admin_priv` bypasses it, as it does for a direct
grant. `REVOKE role` keeps its `grant_priv` gate (a revoke takes nothing).
- Changing another account's credentials needs `admin_priv`. One's own
credentials, and the other `ALTER USER` operations (`ACCOUNT_LOCK` /
`ACCOUNT_UNLOCK`, password policy, comment, TLS), stay under `grant_priv`.
root@'%' keeps its existing rule (only root itself).
### Release note
`GRANT <role> TO <user>` and `CREATE USER ... DEFAULT ROLE` now require the
grantor to hold, besides `grant_priv`, every privilege the role carries (as a
direct `GRANT` does); `admin_priv` is exempt. `ALTER USER ... IDENTIFIED BY`
and `SET PASSWORD FOR` on another account now require `admin_priv`; changing
one's own password is unchanged.
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] 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 <!-- Add your reason? -->
`GrantRoleScopeTest` (real accounts on a test FE): a `grant_priv`-only
account cannot grant a role carrying `SELECT` to itself, to another account or
as a new account's default role, nor the built-in `admin` role; once it holds
the role's privileges it can; `admin_priv` grants any role. The same account
cannot change another account's password by either statement, can change its
own and can lock/unlock another account; an `admin_priv` account can change
another account's password. `SystemRootUserTest`: the two cases where
`grant_priv` changed root@'<host>''s credentials now use an `admin_priv`
account, with the `grant_priv` refusal pinned.
- Behavior changed:
- [ ] No.
- [x] Yes. See the release note: a `grant_priv`-only account loses two
operations it previously had (role grants beyond its own privileges; other
accounts' credentials), both of which amounted to privileges it did not hold.
- Does this need documentation?
- [ ] No.
- [x] Yes. The privilege documentation for `GRANT role`, `ALTER USER`
and `SET PASSWORD`.
### 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]
