[CalvinKirs]

Background

Doris creates root and admin with empty passwords. Operators can set a hashed initial_root_password or set passwords after startup; without either, a newly initialized cluster accepts remote empty-password logins.

What problem does this PR solve?

Issue Number: None
Related PR: None
PR Type: Enhancement

Problem Summary:

Make newly initialized clusters restrict empty-password built-in accounts. Empty root can use only direct loopback MySQL connections and must set a nonempty password before normal SQL; empty admin cannot authenticate as a client until a privileged user sets its password. Existing clusters retain their authentication behavior, and internal JOB, MTMV and statistics identities remain usable.

Details

• Change map: 25 FE production files (+625/-73), four FE test files (+397/-25), nine existing-CI compatibility settings (+25), and threat-model documentation (+29). No BE, Thrift/Protobuf, deployment/tool adapters or new Docker suites are included.
• Before and after: Persist the secure-initialization marker in the existing first-FE journal record and authentication image. Enforce it across MySQL, HTTP, forwarded Stream Load, Flight and certificate authentication. Guard bootstrap SQL and protocol commands, including prepared statements; release the current session only after a successful own-password change.
• Configs and defaults: Add immutable allow_empty_password_for_root_admin=false for explicit test compatibility; it never bypasses a configured nonempty password. Keep the existing boolean skip_localhost_auth_check=false for local recovery. Marked clusters exclude PROXY protocol connections from bootstrap/recovery. Reject invalid nonempty initial_root_password values before writing ROLE/VERSION, without exposing the value.
• Impact on existing users: Unmarked upgraded clusters, including journal-only metadata without an image, retain their policy. Existing CI explicitly enables test compatibility. Deployment tools using remote empty-password accounts need separate adaptation; automated initialization can use the existing hashed initial_root_password.

Testing

• run-fe-ut.sh: 83 passed, zero failures/errors/skips: DefaultAuthenticatorTest (5), MysqlProtoTest (14), UserAuthenticationBindingTest (21), BootstrapAuthenticationTest (16), AuthenticatorManagerTest (27).
• build.sh --fe at 18a0d71b219: BUILD SUCCESS, zero Checkstyle violations. The deployed package's 25 changed production classes match the compiled classes.
• Separate ADBC/Web fixture at the same commit: 35 checks passed, including 15 ADBC checks and 11 Chromium login scenarios across seven phases. The browser scenarios are grouped within the 35 checks, rather than added to that total.

MySQL: manual execution record

The following are excerpts from the author's actual manual session on MySQL port 32375. Passwords are redacted; welcome banners, repeated guidance and blank prompts are omitted.

1. Empty root can connect locally, but must set a password before normal SQL. The same connection becomes usable immediately after setting it.

$ mysql --no-defaults --protocol=TCP -h127.0.0.1 -P32375 -uroot
mysql> show databases;
ERROR 1820 (HY000): errCode = 2, detailMessage = Set a nonempty root password before executing this statement: SET PASSWORD = PASSWORD('...') or ALTER USER root IDENTIFIED BY '...'

mysql> SET PASSWORD = PASSWORD('[REDACTED]');
Query OK, 0 rows affected (0.02 sec)
admin has no password and cannot log in with a password. Run ALTER USER 'admin' IDENTIFIED BY '...' if you need it.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| __internal_schema  |
| information_schema |
| mysql              |
+--------------------+
3 rows in set (0.01 sec)

2. Empty admin is refused. Root's old empty credential is also refused after root sets its password.

$ mysql --no-defaults --protocol=TCP -h127.0.0.1 -P32375 -uadmin
ERROR 1045 (28000): Access denied for user 'admin@127.0.0.1' (using password: NO).

$ mysql --no-defaults --protocol=TCP -h127.0.0.1 -P32375 -uroot
ERROR 1045 (28000): Access denied for user 'root@127.0.0.1' (using password: NO).

3. Root enables admin by setting its password; admin then logs in and executes SQL.

$ mysql --no-defaults --protocol=TCP -h127.0.0.1 -P32375 -uroot -p
mysql> ALTER USER 'admin' IDENTIFIED BY '[REDACTED]';
Query OK, 0 rows affected (0.02 sec)

$ mysql --no-defaults --protocol=TCP -h127.0.0.1 -P32375 -uadmin -p
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| __internal_schema  |
| information_schema |
| mysql              |
+--------------------+
3 rows in set (0.00 sec)

ADBC / Arrow Flight SQL: executed inputs and saved results

The actual ADBC run used a separate fixture: FE MySQL 39945, FE Flight 38985, BE Flight 38965; Python 3.11, ADBC Flight SQL/manager 1.13.0, PyArrow 26.0.1, cached BE 4.1.3-rc02-7126cf65d96. Each probe opened a fresh ADBC connection. Result tables below are rendered from values saved in protocol-results.json.

1. Before setting passwords, Flight rejects root and admin even over loopback.

Executed connection probe	Saved result
root, empty password, 127.0.0.1:38985	UNAUTHENTICATED
root, empty password, FE node address	UNAUTHENTICATED
admin, empty password, 127.0.0.1:38985	UNAUTHENTICATED
admin, empty password, FE node address	UNAUTHENTICATED

2. After setting root's password through local MySQL, ADBC reads both an FE result and real BE data.

The harness executed SET PASSWORD = PASSWORD(%s) through loopback MySQL port 39945, binding the generated root password. SHOW DATABASES then succeeded on that same connection.

Executed over ADBC as root through both loopback and the FE node address:

SELECT 42 AS answer;

Recorded FE result:

+--------+
| answer |
+--------+
|     42 |
+--------+

SELECT id, label FROM bootstrap_protocol_e2e.protocol_probe ORDER BY id;

Recorded BE result:

+----+-------+
| id | label |
+----+-------+
|  1 | alpha |
|  2 | beta  |
|  3 | gamma |
+----+-------+

Recorded Arrow schema: id: int32, label: string. The FE result was checked with cursor.fetchone() == (42,); BE rows were fetched with cursor.fetch_arrow_table(). A deliberately wrong root password was rejected with UNAUTHENTICATED; admin still could not log in with an empty password.

3. Admin activation, resetting passwords to empty, restart and test compatibility were then exercised.

Operation actually performed	Fresh ADBC connection's saved result
Root sets admin's password with ALTER USER 'admin' IDENTIFIED BY '[REDACTED]'	Admin returns 42 and the same three BE rows.
Root executes SET PASSWORD FOR 'admin'@'%' = PASSWORD('')	Admin: UNAUTHENTICATED.
Root executes SET PASSWORD = PASSWORD('')	Root: UNAUTHENTICATED. Root's nonempty password was then restored through local MySQL.
Restart FE with protection enabled	Root returns 42 and the BE rows; empty admin remains rejected.
Reset root to empty, set allow_empty_password_for_root_admin=true, and restart FE	Both empty-password root and admin return 42 and the BE rows; skip_localhost_auth_check remains false.

ADBC fixture setup, executed client code and complete PASS log

The fixture used new metadata and one healthy BE. A temporary hashed initial_root_password was used only to register the BE; root was reset to empty, the configuration entry removed, and FE restarted before the matrix. Admin remained empty and the secure-initialization marker persisted. Both bypass settings were false, and effective HTTP authentication was true. Local settings were be_exec_version=10, enable_local_shuffle_planner=false, BE mem_limit=2G; client proxies were removed.

Actual harness command (the local harness is not included in this PR):

.idea/bootstrap-venv/bin/python .idea/bootstrap-web-flight-test.py > .idea/bootstrap-web-flight-test.log 2>&1

Executed ADBC connection helper, copied from that harness:

def adbc_connection(user, password, host='127.0.0.1'):
    return flightsql.connect(f"grpc://{host}:{STATE['ports']['fe_flight']}",
                            db_kwargs={adbc.DatabaseOptions.USERNAME.value: user,
                                       adbc.DatabaseOptions.PASSWORD.value: password}, autocommit=True)

Saved query-result fields:

{
  "feConstant": 42,
  "beRows": [[1, "alpha"], [2, "beta"], [3, "gamma"]],
  "schema": "id: int32\nlabel: string"
}

The table was created and populated through MySQL before the positive ADBC probes:

CREATE DATABASE IF NOT EXISTS bootstrap_protocol_e2e;
DROP TABLE IF EXISTS bootstrap_protocol_e2e.protocol_probe;
CREATE TABLE bootstrap_protocol_e2e.protocol_probe (id INT, label VARCHAR(32))
DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES ("replication_num"="1");
INSERT INTO bootstrap_protocol_e2e.protocol_probe
VALUES (1,'alpha'),(2,'beta'),(3,'gamma');

Actual ADBC-related output from the final successful run:

PASS: Fresh cluster empty root Flight from 127.0.0.1
PASS: Fresh cluster empty root Flight from 172.20.32.136
PASS: Fresh cluster empty admin Flight from 127.0.0.1
PASS: Fresh cluster empty admin Flight from 172.20.32.136
PASS: ADBC root FE result and BE Arrow table result
PASS: ADBC root remote-address connection and BE query
PASS: ADBC root wrong password rejected
PASS: Admin stays disabled after root setup
PASS: ADBC admin enabled by root and BE query
PASS: ADBC admin set back to empty is rejected
PASS: ADBC root set back to empty is rejected
PASS: ADBC root works after FE restart
PASS: Admin empty stays rejected after FE restart
PASS: ADBC explicit test compatibility for empty root
PASS: ADBC explicit test compatibility for empty admin

Web and validation scope

Real Chromium exercised sign-in, the Playground's JDBC-backed SQL session, the same three-row BE query and sign-out. The run also covered Cookie/CSRF authentication, SQL-session creation/closure and the legacy Web SQL API, including empty-password rejection, admin activation, resetting passwords to empty, FE restart and explicit test compatibility.

The 35-check run used the isolated fixture. A later authenticated recheck of the manually modified demo returned UNAUTHENTICATED before querying and contributed zero passed checks. The isolated fixture was stopped afterwards, its compatibility setting restored to false and temporary credentials removed.

Earlier local runtime checks covered direct/follower password-reset success and rejection, admin-empty JOB/MTMV execution across restart, statistics, audit import and group commit with cached BE 4.1.3. These were not rerun after the final internal API cleanup. Full cloud MS, a real mTLS provider matrix, downgrade round trips and a fresh COM_CHANGE_USER wire exchange were not exercised.

Notes for Reviewers

Start with BootstrapAuthPolicy, BootstrapPasswordGuard and the first-FE marker journal/replay path in Env. Optional fields reuse an existing operation code. Existing authenticated sessions are not revoked by password changes. Marker preservation through downgrade/checkpoint/re-upgrade is not promised.

Release note

New clusters restrict empty-password root to local MySQL password initialization and reject empty-password admin client logins. Configure a hashed initial_root_password before first startup for automation, or initialize root locally and set admin's password when needed. Existing clusters retain their behavior. Tests can explicitly enable allow_empty_password_for_root_admin.

Check List (For Author)

• Behavior changed: Yes (see Details).
• Does this need documentation: Yes; threat-model documentation is updated. Matching quickstart and FE configuration guidance is planned for apache/doris-website.
• Pre-submission status: Partially verified: FE tests, build/style and local ADBC/Web checks passed; full cloud MS, real mTLS and downgrade round trips were not exercised.

AI Disclosure

• Tool: Codex (GPT-6).
• Generated: FE code, tests, documentation and this PR description.
• Human review: Pending maintainer review.

[CalvinKirs]

run buildall