[fix](auth)Fix arrow flight client ip auth#63506
Merged
CalvinKirs merged 3 commits intoMay 25, 2026
Merged
Conversation
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Member
Author
|
run buildall |
Member
Author
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Reviewed PR 63506 against the Doris code-review checklist and threat model.
Critical checkpoint conclusions:
- Goal/test coverage: The PR fixes Arrow Flight SQL password authentication to use the real gRPC peer IP instead of always using 0.0.0.0. The unit test covers tracer extraction/fallback and the regression test exercises host-qualified authentication through Arrow Flight SQL.
- Scope/focus: The implementation is small and focused on FE Arrow Flight auth plus tests.
- Concurrency/lifecycle: The gRPC Context holder is per-call; no shared mutable cross-call state was introduced. The holder value is only used during call authentication and token creation.
- Configuration/compatibility: No new config, storage format, or FE-BE protocol compatibility concern.
- Parallel paths: This aligns Arrow Flight credential auth with existing MySQL-style remote-host password checks; bearer-token session creation continues to use the remote IP captured at initial credential authentication.
- Error handling: Authentication failures continue through the existing Arrow Flight UNAUTHENTICATED path.
- Observability: Existing auth failure logging remains; no additional observability appears required for this focused fix.
- Security/threat model: FE Arrow Flight is an in-scope client-facing endpoint. The change improves RBAC/auth host matching and does not add reverse-proxy header trust or broaden the boundary.
- User focus: No additional user-provided review focus was specified.
No blocking issues found.
Contributor
TPC-H: Total hot run time: 31606 ms |
Contributor
TPC-DS: Total hot run time: 169467 ms |
Contributor
FE Regression Coverage ReportIncrement line coverage |
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: The Arrow Flight remote IP authentication regression creates host-specific users and grants only SELECT_PRIV. In cloud mode those authenticated users also need compute group usage privilege before SELECT 1 can execute.
### Release note
None
### Check List (For Author)
- Test: Manual test
- Ran `git diff --check`
- Attempted regression test with `timeout 45 ./run-regression-test.sh --run -d arrow_flight_sql_p0 -s test_auth_remote_ip`, but the local cluster failed before the Arrow Flight query because BE nodes were not alive: `No backend available as scan node`
- Behavior changed: No
- Does this need documentation: No
Member
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 31258 ms |
Contributor
TPC-DS: Total hot run time: 169080 ms |
Contributor
FE UT Coverage ReportIncrement line coverage |
Member
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 31003 ms |
Contributor
TPC-DS: Total hot run time: 168666 ms |
Contributor
FE Regression Coverage ReportIncrement line coverage |
Member
Author
|
/review |
Contributor
|
OpenCode automated review failed and did not complete. Error: Review step was failure (possibly timeout or cancelled) Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
morrySnow
approved these changes
May 25, 2026
github-actions
Bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
Contributor
There was a problem hiding this comment.
Review completed. I did not find a blocking issue in the live PR diff. The implementation uses a gRPC ServerStreamTracer to capture the peer address before Arrow Flight header authentication and passes that IP into Doris password/user@host matching; the token/session path then preserves the authenticated remote IP. The regression test covers fallback from the old hardcoded 0.0.0.0 behavior by creating that host entry with a wrong password and creating likely local/private remote host patterns with the valid password.\n\nCritical checkpoint conclusions:\n- Goal/test: The code addresses the stated Arrow Flight user@host auth issue and includes unit plus regression coverage.\n- Scope: The live PR is focused on Arrow Flight auth remote IP and its test.\n- Concurrency: The tracer is per stream; shared state is only a gRPC Context key with a per-call holder, so no cross-call state issue found.\n- Lifecycle/static init: No static initialization-order or special lifecycle issue found.\n- Config: No new config items.\n- Compatibility: No storage/protocol compatibility issue found; default fallback remains 0.0.0.0 when no peer address is available.\n- Parallel paths: Basic credential auth is the relevant path; bearer token/session creation consumes the captured IP through existing token details.\n- Conditional checks: Fallback handling for missing/non-INET peer address is reasonable.\n- Tests: Coverage is adequate for the changed behavior; I did not run tests in this review environment.\n- Observability: Existing auth errors/logging remain sufficient.\n- Transaction/persistence/data writes: Not applicable.\n- FE/BE variable passing: Not applicable.\n- Performance: No meaningful overhead beyond per-call tracer allocation/address extraction.\n\nThreat-model/user focus: FE Arrow Flight authentication is an in-scope client-facing auth path; no additional user-provided review focus was supplied.
github-actions Bot
pushed a commit
that referenced
this pull request
May 25, 2026
## Changes In Doris 4.1.0, Arrow Flight SQL authentication may fail for users created with a specific host/IP. Example input: ```sql CREATE USER 'read_user'@'192.0.2.10' IDENTIFIED BY '12345'; GRANT SELECT_PRIV ON *.* TO 'read_user'@'192.0.2.10'; ``` Then connect through Arrow Flight SQL with the same username and password, for example by ADBC/Python or Arrow Flight JDBC. Actual wrong output: ``` UNAUTHENTICATED: [FlightSQL] Unable to authenticate user read_user, exception: errCode = 2, detailMessage = Access denied for user 'read_user@0.0.0.0' (using password: YES) ``` Expected output: ``` The user should be authenticated as the real remote client identity, for example: read_user@192.0.2.10 and the connection should succeed when the password and privileges match that user@host. ``` Root cause: Arrow Flight SQL previously used hardcoded remote IP 0.0.0.0 during username/password authentication. As a result, Doris matched the wrong user@host entry instead of using the actual client IP from the gRPC connection. This PR fixes Arrow Flight SQL authentication to use the real gRPC peer IP when validating credentials.
This was referenced May 25, 2026
github-actions Bot
pushed a commit
that referenced
this pull request
May 25, 2026
## Changes In Doris 4.1.0, Arrow Flight SQL authentication may fail for users created with a specific host/IP. Example input: ```sql CREATE USER 'read_user'@'192.0.2.10' IDENTIFIED BY '12345'; GRANT SELECT_PRIV ON *.* TO 'read_user'@'192.0.2.10'; ``` Then connect through Arrow Flight SQL with the same username and password, for example by ADBC/Python or Arrow Flight JDBC. Actual wrong output: ``` UNAUTHENTICATED: [FlightSQL] Unable to authenticate user read_user, exception: errCode = 2, detailMessage = Access denied for user 'read_user@0.0.0.0' (using password: YES) ``` Expected output: ``` The user should be authenticated as the real remote client identity, for example: read_user@192.0.2.10 and the connection should succeed when the password and privileges match that user@host. ``` Root cause: Arrow Flight SQL previously used hardcoded remote IP 0.0.0.0 during username/password authentication. As a result, Doris matched the wrong user@host entry instead of using the actual client IP from the gRPC connection. This PR fixes Arrow Flight SQL authentication to use the real gRPC peer IP when validating credentials.
yiguolei
pushed a commit
that referenced
this pull request
May 25, 2026
yiguolei
pushed a commit
that referenced
this pull request
May 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
In Doris 4.1.0, Arrow Flight SQL authentication may fail for users created with a specific host/IP.
Example input:
Then connect through Arrow Flight SQL with the same username and password, for example by ADBC/Python or Arrow Flight JDBC.
Actual wrong output:
Expected output:
Root cause:
Arrow Flight SQL previously used hardcoded remote IP 0.0.0.0 during username/password authentication. As a result, Doris matched the wrong user@host entry
instead of using the actual client IP from the gRPC connection.
This PR fixes Arrow Flight SQL authentication to use the real gRPC peer IP when validating credentials.