Password Expiration Handling with PROXY Privilege in MariaDB: Diagnostic Question

Direct Answers

1. Evaluation order: MariaDB authenticates the connecting account, resolves the PROXY mapping to determine the effective (proxied) user, and then checks whether that effective account's password is expired. The proxy chain is evaluated before the password-expiry enforcement.
2. Privileged operations while expired: No. Once the effective (proxied) user's password is expired, the server returns ER_PASSWORD_EXPIRED (error 1862, SQLSTATE 28000) and rejects all statements except SET PASSWORD. No SELECT, DDL, or other operation—even on schemas accessible only through the proxied user—can execute until the password is changed.
3. Client library behavior: Connector/J, Connector/C, and the native mysql client all surface ER_PASSWORD_EXPIRED as a SQLException (SQLState 28000) and prevent further statement execution. A generic ER_ACCESS_DENIED_ERROR from a client indicates a client-side mapping difference (older driver, misconfigured error handling), not a server behavior change. There is no server system variable or client option to alter the evaluation order; the sequence is fixed in MariaDB 10.5+.

Confirmed Behavior (MariaDB 10.5+, including 10.6+)

The server's authentication flow follows this sequence:

1. Validate credentials for the connecting account (the proxy user).
2. If the account holds PROXY privilege on a target user, resolve the proxied user and adopt its privileges for the session.
3. Check the effective user's password expiration status. If expired, return ER_PASSWORD_EXPIRED and enter "sandbox" mode: only SET PASSWORD (or equivalent ALTER USER ... PASSWORD EXPIRE NEVER by a privileged admin) is permitted.

Because the expiry check occurs after proxy resolution, the proxied user's expired password blocks the session entirely. The connecting proxy user's own password status is checked first; if that account is expired, the same error is returned before proxy resolution even begins.

Verification Steps

Run the following on your MariaDB 10.6+ instance to confirm the behavior:

-- 1. Create proxy and target users
CREATE USER 'proxy_user'@'%' IDENTIFIED BY 'proxy_pass';
CREATE USER 'target_user'@'%' IDENTIFIED BY 'target_pass';
GRANT PROXY ON 'target_user'@'%' TO 'proxy_user'@'%';
GRANT SELECT ON protected_schema.* TO 'target_user'@'%';

-- 2. Expire the target (proxied) user's password
ALTER USER 'target_user'@'%' PASSWORD EXPIRE;

-- 3. Connect as proxy_user and attempt a privileged operation
-- Using the mysql client:
mysql -u proxy_user -pproxy_pass -e "SELECT * FROM protected_schema.sensitive_table;"

-- Expected: ERROR 1862 (HY000): Your password has expired.

-- 4. Reset the password and verify access is restored
mysql -u proxy_user -pproxy_pass -e "SET PASSWORD FOR 'target_user'@'%' = 'new_target_pass';"
mysql -u proxy_user -pnew_target_pass -e "SELECT * FROM protected_schema.sensitive_table;"
-- Expected: query succeeds

Check the raw error code in your application logs or the server error log (log_error) to confirm 1862 is returned, not 1045 (ER_ACCESS_DENIED_ERROR).

One Diagnostic Detail Needed

If you are seeing ER_ACCESS_DENIED_ERROR instead of ER_PASSWORD_EXPIRED, please specify the exact client library and version (e.g., Connector/J 2.7.5, Connector/C 3.3.2, mysql client 10.6.12). This determines whether the issue is a client-side error mapping that can be fixed by upgrading or configuring the driver, rather than a server behavior difference.