Skip to content

branch-4.1: [fix](auth) Treat only root@'%' as root in SET PASSWORD and ALTER USER - #68634

Merged
yiguolei merged 1 commit into
apache:branch-4.1from
CalvinKirs:backport-68559-branch-4.1
Sep 29, 2026
Merged

yiguolei merged 1 commit into
apache:branch-4.1from
CalvinKirs:backport-68559-branch-4.1

Conversation

@CalvinKirs

Copy link
Copy Markdown
Member

apache#68559)

### What problem does this PR solve?

Issue Number: None

Related PR: apache#50904

Problem Summary:

apache#50904 made only `root@'%'` and `admin@'%'` system users
(`UserIdentity.isRootUser()` / `isSystemUser()` compare the full
identity), so `CREATE USER 'root'@'8.8.20.39'` is allowed and creates an
ordinary account, and `DROP USER` drops it. `SET PASSWORD` and `ALTER
USER` were not updated and still decide "is this root" from the user
name alone, ignoring the host:

```sql
CREATE USER 'root'@'8.8.20.39' IDENTIFIED BY 'Pwd_a1';
SET PASSWORD FOR 'root'@'8.8.20.39' = PASSWORD('Pwd_b2');
-- ERROR: Can not set password for root user, except root itself
```

- `SetPassVarOp` refuses every target named `root` other than the
current user itself, so nobody, `root@'%'` included, can set the
password of `root@'8.8.20.39'`.
- `AlterUserInfo` refuses `ACCOUNT_LOCK` on every account named `root`
("Can not lock root user"), and compares both the target and the current
user by name for "Only root user can modify root user", so a GRANT user
can not `ALTER USER 'root'@'8.8.20.39'`, and every account named `root`
counts as `root@'%'` there.

This PR uses `UserIdentity.isRootUser()` in these checks, for the target
and, in `AlterUserInfo`, for the current user as well, the predicate
`CREATE USER` and `DROP USER` already use (`SetPassVarOp` already
compares the full identity for "root itself"). `root@'<host>'` is now
managed like any other account by a user with GRANT privilege, while
`root@'%'` can still only be modified by `root@'%'` itself and still can
not be locked.

### Release note

`SET PASSWORD` and `ALTER USER` now treat only `root@'%'` as the root
user. An account created as `root@'<host>'` can have its password
changed, and be altered or locked, by a user with GRANT privilege like
any other account.

### Check List (For Author)

- Test <!-- At least one of them must be included. -->
    - [x] Regression test
    - [x] Unit Test
    - [x] 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?  -->

- FE UT: new `SystemRootUserTest` and
`AccountLockTest#testRootAtSpecificHostCanBeLocked`, both failing
without the fix; `SetPasswordTest`, `AlterUserStmtTest`,
`AlterUserCommandTest`, `SetPasswordParseTest`, `EncryptSQLTest`,
`AuthTest` still pass.
- Regression: `account_p0/test_system_user` (extended), plus
`test_root_user`, `test_set_password`, `test_account_lock`,
`test_alter_user`, on a local FE built from this branch.
- Manual: the statements above, then `ALTER USER 'root'@'8.8.20.39'
ACCOUNT_LOCK / ACCOUNT_UNLOCK` and `DROP USER 'root'@'8.8.20.39'`, all
succeed; `ALTER USER 'root'@'%' ACCOUNT_LOCK` is still rejected.

(cherry picked from commit bf98529)
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@CalvinKirs

Copy link
Copy Markdown
Member Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 100.00% (2/2) 🎉
Increment coverage report
Complete coverage report

@yiguolei

Copy link
Copy Markdown
Contributor

skip buildall

@yiguolei
yiguolei merged commit b69fc36 into apache:branch-4.1 Sep 29, 2026
32 of 33 checks passed
yiguolei pushed a commit that referenced this pull request Oct 8, 2026
@yiguolei yiguolei mentioned this pull request Oct 10, 2026
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.

3 participants