Doris-Breakwater commented on issue #70437: URL: https://github.com/apache/doris/issues/70437#issuecomment-6763860276
Breakwater-GitHub-Analysis-Slot: slot_a41c34f18153 The reported root cause is supported by the source at **`917b20be83878e98f94e3ebf7efccc80346e3e50`**, which the local `4.1.5-release` tag resolves to. This warrants FE / LDAP / HTTP authentication bug triage. This is source verification against the reported build; I have not independently reproduced it with a running FE and LDAP server. **Verified authentication path** 1. [`LoginController.login`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/httpv2/controller/LoginController.java#L36-L47) calls `checkWithCookie(..., false)`. With a Basic Authorization header, this reaches `checkPassword`; the assertion at line 284 matches the supplied stack exactly. It runs before session creation and before any subsequent admin-page authorization. See [`BaseController`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/httpv2/controller/BaseController.java#L264-L285). 2. [`Auth.checkPlainPassword`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/Auth.java#L236-L252) selects LDAP for an LDAP-existing user. [`LdapManager.checkUserPasswd`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/mysql/authenticate/ldap/LdapManager.java#L173-L178) can return success while adding **zero identities**. Its identity lookup ultimately scans existing local, non-domain users whose host patterns match the request address; it never synthesizes an identity. See [`UserManager`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/UserManager.java#L192-L206). Successful LDAP authentication therefore does not imply the HTTP caller's required list size of one. 3. The working MySQL path explicitly handles an empty identity list: [`LdapAuthenticator.internalAuthenticate`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/mysql/authenticate/ldap/LdapAuthenticator.java#L110-L142) creates an identity from the username and remote IP and marks the authentication result temporary. The HTTP path lacks this handling. This explains the reported LDAP-only failure without requiring an operator or Kubernetes fault. LDAP password validation may use its cache, so the stack alone does not prove a fresh LDAP bind occurred. It also does not independently establish the identity-list size; zero follows from the stated absence of a local account. **Login and admin-page access need separate treatment** LDAP privileges are resolved by username through [`Auth.getRolesByUserWithLdap`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/Auth.java#L274-L298). Group names map to existing Doris roles; this build also includes configured LDAP default roles. Successful authentication alone does not grant `ADMIN_OR_NODE`. The minor message issue is also supported by code: [`checkCookie`](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/fe/fe-core/src/main/java/org/apache/doris/httpv2/controller/BaseController.java#L133-L150) returns null when an existing session fails the privilege check. The caller turns this into `Cookie is invalid`, and the [UI maps that response to its expiration dialog](https://github.com/apache/doris/blob/917b20be83878e98f94e3ebf7efccc80346e3e50/ui/src/utils/request.tsx#L123-L140). This should be tracked as a distinct authorization-message defect while preserving the privilege requirement. [The earlier report, #46281](https://github.com/apache/doris/issues/46281), described the same symptom on 2.1.7. Its [maintainer response](https://github.com/apache/doris/issues/46281#issuecomment-2571316757) noted administrative UI restrictions, and its [closure comment](https://github.com/apache/doris/issues/46281#issuecomment-3283042126) cites inactivity. That closure is not evidence of a fix. The present source supports a continuing HTTP identity-resolution gap; a newly introduced regression is not established. **Suggested maintainer next steps** - Reuse the LDAP identity-resolution semantics of the MySQL authenticator after successful credential validation: retain a matching local identity when present and produce a temporary identity otherwise. Review temporary-user state across HTTP session creation and cookie-restored contexts as part of that change. Merely removing the assertion leaves `get(0)` failing; granting admin privileges does not resolve the missing identity. - Add HTTP regression coverage for LDAP-only login, incorrect LDAP passwords, LDAP users with local identities, host-pattern selection, and ordinary local-account login. Verify both Basic and cookie requests: a suitably privileged LDAP role can access protected pages, while an unprivileged user can authenticate but receives a clear permission denial on those pages. - Keep missing/expired sessions distinguishable from insufficient privileges. Existing `BaseControllerBasicAuthTest` overrides `checkPassword`, so its successful-login test does not exercise this LDAP identity gap. **Remaining runtime confirmation** The report is sufficient for code-level triage. To confirm the deployed behavior, please provide a timestamp-correlated, sanitized FE log excerpt for one login attempt and confirm that MySQL and HTTP reach the same FE build, preferably by testing one FE pod directly. Include the FE image digest/build identification and operator version, relevant non-secret authentication settings, whether an external authorization provider is enabled, and confirmation that no local identity exists for the affected username. For permission-message verification, also include the relevant LDAP-to-role mapping and role grants, with identifying values anonymized consistently. Do not include passwords, Authorization headers, or session-cookie values. A query profile is not needed for this pre-query failure. Until a fix is validated, the already-working MySQL path remains an available access route. No upgrade is asserted to fix this issue, and no source code was changed during this investigation. -- 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]
