proxysql

Commit Graph

Author	SHA1	Message	Date
Rene Cannao	58b26edba9	fix(passthrough-auth): populate session defaults for empty-pw cache-miss path The TLS test enablement (commits 4d47878..29698c5) exposed a latent crash in the pass-through dispatch state machine. With TLS on the frontend leg, the caching_sha2_password full-auth exchange completes for the first time end-to-end in CI: client HandshakeResponse (hashed empty pw, plugin=caching_sha2) -> ProxySQL: PPHR_verify_password (cache miss for empty-pw row) -> PPHR_passthrough_init stage 0 (send AuthMoreData{0x04}) -> client sends cleartext over TLS -> ProxySQL: PPHR_1 (stage 4 -> stage 5, return rc=2) -> __do_auth -> PPHR_verify_password (cache STILL miss) -> PPHR_passthrough_init stage 5 (set state AUTHENTICATING_BACKEND_FOR_CLIENT) -> handler_again___status_AUTHENTICATING_BACKEND_FOR_CLIENT runs -> CRASH Backtrace (from ci_infra_logs/ci-mysql84-g4/proxysql/proxysql.log): MyHGC.cpp:355:get_random_MySrvC(): [ERROR] Hostgroup 4294967295 has no servers available! proxysql: MySQL_Protocol.cpp:242: bool MySQL_Protocol::generate_pkt_ERR(...): Assertion `0' failed. Error: signal 6: ... ---- handler_again___status_AUTHENTICATING_BACKEND_FOR_CLIENT() ---- MySQL_Session::handler() ---- MySQL_Thread::process_all_sessions() Root cause: `4294967295` is `UINT32_MAX`, i.e. `(uint32_t)-1`. The session's `default_hostgroup` was still at its `MySQL_Session::reset()` sentinel (-1) when `handler_again___status_AUTHENTICATING_BACKEND_FOR_CLIENT` read it as `target_hg` (lib/MySQL_Session.cpp:1899). `MyHGC_lookup` treats the value as unsigned, finds no hostgroup with that id, the handler calls `fail_session("no hostgroup")`, and the subsequent `generate_pkt_ERR` call then trips its DSS-state switch's `assert(0)` because the data stream is in a state the switch doesn't enumerate. Why default_hostgroup wasn't set: in `PPHR_verify_password`, the pass-through dispatch has three branches at the cache lookup point: 1. CACHE HIT -- falls through to PPHR_5passwordTrue (further down in the function) which unconditionally pushes account_details.default_hostgroup, default_schema, schema_locked, transaction_persistent, session_fast_forward, user_max_connections onto the session. WORKS. 2. UNKNOWN_USER + cache miss -- a dedicated population block (line ~2660) synthesizes routing defaults from mysql-passthrough_default_hg / mysql-passthrough_default_schema globals before driving PPHR_passthrough_init. WORKS. 3. EMPTY-PW ROW + cache miss -- DOES NOT populate the session. Goes straight to PPHR_passthrough_init for the AuthMoreData{0x04} round-trip. When control later returns and lands in AUTHENTICATING_BACKEND_FOR_CLIENT, default_hostgroup is still the reset sentinel. CRASHES. This was latent because non-TLS clients fail the caching_sha2 full-auth exchange earlier in the protocol (mysql client errno 2061, "Couldn't read RSA public key from server" -- ProxySQL's PPHR_passthrough_init does not implement the 0x02 public-key-request branch). The CI tests had `mysql-passthrough_auth_require_tls=false` and connected without CLIENT_SSL, so the cache-miss + empty-pw path never reached the probe handler. Enabling TLS in those tests (F8-F13) finally drove an end-to-end probe and exposed the crash. Fix: in the cache-miss + empty-pw row branch of PPHR_verify_password, call PPHR_5passwordTrue immediately before PPHR_passthrough_init. The helper is purely a field-setter (no side effects, idempotent across the two cache-miss visits the state machine makes -- once at stage 0, once at stage 5) and pushes the same routing/schema fields onto the session that the cache-hit path would set later via the existing PPHR_5passwordTrue call site. The call is gated on `!unknown_user_case` because unknown_user_case's account_details is a value-initialized struct (zeros + nullptr) and would silently clobber the synthesized defaults that block at line ~2660 just applied from globals. After this fix: - Cache HIT path: unchanged (PPHR_5passwordTrue still called via fallthrough; the early call here is short-circuited because the cache lookup matched before reaching this branch). - UNKNOWN_USER + cache miss: unchanged (unknown_user_case gate skips the new call; the existing globals-population block at line ~2660 still runs). - EMPTY_PW + cache miss: session now has valid default_hostgroup (and default_schema, transaction_persistent, etc.) before AUTHENTICATING_BACKEND_FOR_CLIENT reads them. The probe routes through the correct hostgroup; on success the credential gets cached with target_hg=row's default_hostgroup as the spec requires. An exhaustive Doxygen comment above the new call documents the discovery context, the crash signature, and the architectural distinction between the three dispatch branches -- so a future maintainer understands why this call exists and why it's gated on !unknown_user_case. Verified the file compiles cleanly via the project Makefile (obj/MySQL_Protocol.oo rebuilt from scratch).	1 month ago
Rene Cannao	a050d0d431	fix(passthrough-auth): gate cache eviction on credential-was-from-cache The ER_ACCESS_DENIED_ERROR (1045) eviction hook in handler_again___status_CONNECTING_SERVER fired unconditionally on any 1045 for the session's username. A regular mysql_users user with a stale stored hash that triggered 1045 would silently evict an unrelated pass-through cache entry for the same username. Functionally this is harmless (next pass-through connect re-probes and re-populates the cache), but it creates needless churn on rotation events for users who aren't using pass-through at all, and the metric cache_invalidations becomes noisy. Add a per-session @c passthrough_credential bool on MySQL_Session: - Initialized to @c false in MySQL_Session::reset() alongside the other auth-state flags. - Set to @c true in PPHR_verify_password on a cache hit (the credential we're verifying with literally came from the cache). - Set to @c true in handler_again___status_AUTHENTICATING_BACKEND_FOR_CLIENT after a probe success (we just inserted the cleartext into the cache, so a future ER 1045 on this session means our just-cached cleartext is stale). The eviction hook now checks this flag before evicting; non- pass-through sessions cannot invalidate the cache. This makes cache_invalidations a clean signal for "pass-through sessions whose cached cleartext was rejected by the backend". Discovered as N4 / a GA-blocker by the production-readiness subagent during the round-3 deep review of PR #5810.	1 month ago
Rene Cannao	d907797944	fix(passthrough-auth): compute password once in COM_CHANGE_USER reject Commit `28a72c9c5` introduced the early-rejection check in process_pkt_COM_CHANGE_USER. The rejection block called get_password() to inspect the row's stored password, freed the result, and then the legacy code path immediately below called get_password() AGAIN to drive the rest of the handler. get_password() has an in-source contract documented as "Only count one attempt using the cache per connection": when it returns the cached clear_text_password[PRIMARY] it bumps MyHGM->status.client_connections_sha2cached. The double call broke that contract by bumping the counter twice on every CHANGE_USER where: - the user has a clear_text_password cached, AND - the pass-through rejection gate did NOT fire (most CHANGE_USERs in practice, since pass-through opt-in is rare) Fix: compute @c password ONCE before the rejection check and reuse it for the rest of the handler. The previously-shadowed local @c password is now the same variable referenced by the rejection block, so: - the rejection cleanup frees @c password (and NULLs it), - the legacy path uses @c password directly, - on every exit path through this function, get_password() is called exactly once. Side note: this restructure also makes the rejection block slightly easier to read -- the scope braces are gone and the control flow is linear. Discovered in the round-3 deep review of PR #5810 (finding #1 from the fix-verification subagent).	1 month ago
Rene Cannao	8dfe921ad4	feat(passthrough-auth): counters + stats_mysql_passthrough_auth_metrics Adds operational-visibility metrics for the pass-through auth feature. Previously the only diagnostics available to an SRE were the audit log (optional, often off) and proxy_warning (added in the preceding commit). Both are good but neither lets an operator answer "is anything happening?" / "how often does pass-through succeed?" at a glance. Nine atomic counters added to MySQL_Passthrough_Auth_Cache, incremented at the single well-defined call site each: probes_attempted -- a real probe was about to run (past all eligibility gates, past inflight cap, past rate limits) probes_ok -- probe succeeded, cache populated probes_failed_credentials -- probe got 1045/1698/1130 from backend probes_failed_transport -- probe got 2xxx / unknown errno lockouts_user -- per-user lockout fired lockouts_ip -- per-IP lockout fired inflight_cap_rejects -- max_inflight_probes saturated cache_hits -- PPHR_verify_password used the cache cache_invalidations -- backend ER 1045 evicted a cached entry Plus two current-state gauges (read on demand from existing methods): inflight_probes -- current Glo->inflight() cache_entries -- current Glo->size() Exposed via a new admin virtual table: stats_mysql_passthrough_auth_metrics( metric_name VARCHAR NOT NULL PRIMARY KEY, metric_value BIGINT NOT NULL ) stats___mysql_passthrough_auth_metrics is registered alongside the existing stats___mysql_passthrough_auth_cache; both refresh from GloMyPTAuthCache on SELECT. All counter ops use std::memory_order_relaxed -- stats are advisory and don't need to synchronize with the increments. Counters are monotonic since process start; reset only by process restart. Phase 2 may add a Prometheus exposer alongside this; for now the admin table is the canonical surface for monitoring integrations. Discovered by the production-readiness subagent during the second deep review of PR #5810. Listed there as a blocker for production GA because operational visibility into pass-through misbehavior was effectively zero.	1 month ago
Rene Cannao	39806e353f	fix(passthrough-auth): drop dead use_ssl assignment + empty server_addr JSON Two minor follow-ups from the new-code-quality review pass: C3 (dead store, lib/MySQL_Protocol.cpp ~L2694): account_details.use_ssl = false in the unknown-user cache-hit synthesis block was a dead assignment. PPHR_5passwordTrue doesn't consume that field directly (the relevant copy lives in PPHR_SetConnAttrs via vars1, not via account_details), and the account_details_t value-initialization already gives us false for unknown users. Drop the assignment and document the reasoning inline so a future reader doesn't restore it. C4 (empty server_addr in pass-through audit JSON, lib/MySQL_Logger.cpp ~L1895): log_audit_entry called me.set_server(hid, "", 0) when the hostgroup override fired, which populated MySQL_Event::server with a non-NULL "" pointer. write_auth then unconditionally emitted j["server_addr"] = "" for every pass-through audit entry -- polluting the on-wire schema with an always-empty key. Pass NULL/0 instead so set_server leaves @c server at NULL and the write_auth check (if (server) { ... }) correctly omits the field. Pass-through audit entries no longer carry a useless empty server_addr. Discovered by the new-code-quality and fix-verification subagents during the second deep review of PR #5810.	1 month ago
Rene Cannao	28a72c9c5b	fix(passthrough-auth): reject CHANGE_USER before mutating session state process_pkt_COM_CHANGE_USER unconditionally copies attributes from the lookup-result account_details onto the live session BEFORE authentication is verified: sess->default_hostgroup = account_details.default_hostgroup; sess->transaction_persistent = account_details.transaction_persistent; free(sess->user_attributes); sess->user_attributes = account_details.attributes; The previous version of the pass-through rejection block sat AFTER those mutations. For a CHANGE_USER targeting a pass-through-eligible user that we then reject, the rejected attempt had a side effect: the session's already-authenticated state was now grafted with the target row's routing / transaction semantics / user_attributes. That's an observable side-effect from a rejected attempt -- benign when the upstream fatal-closes on ret=false, but a meaningful security property when the session continues. The cleaner fix is to do the rejection check BEFORE the mutations: we obtain a temporary early_password via get_password(), evaluate the gate, and either return out with the session untouched or fall through to the legacy path. The temporary buffer is explicitly freed in both branches. The existing legacy failure paths (password==NULL, etc.) still exhibit the same pre-mutation property since they too were authored as authentication-first / state-mutation-first. That's project-wide and out of scope here; this commit only ensures the new pass-through rejection doesn't make it WORSE. Discovered by the new-code-quality subagent during the second deep review of PR #5810.	1 month ago
Rene Cannao	38ac143f4d	fix(passthrough-auth): implement username_pattern allowlist mysql-passthrough_auth_username_pattern was registered as a global variable (spec §3.3) and documented as the primary mitigation for unknown-user enumeration (spec §7.1, security model), but never read anywhere in the auth path. Dead code: an admin could SET the pattern and observe no behavioral change. With passthrough_auth_unknown_users=true and a permissive default per-IP limit (10/60s), that was a meaningful enumeration surface. Implement: MySQL_Passthrough_Auth_Cache::username_allowed(username, pattern) Uses RE2 (already a project dependency, used by query rules) with FullMatch semantics. The compiled regex is cached on the class behind a dedicated pattern_lock; the cache key is the pattern string itself, so changing mysql-passthrough_auth_username_pattern at runtime picks up on the next probe attempt without a restart or FLUSH. Failure modes are fail-safe: - empty pattern -> allow all (preserves back-compat default) - non-compiling regex -> deny all (a misconfigured allowlist must NOT default to permitting every username; that would re-open exactly the surface the pattern exists to gate) Hooked into PPHR_verify_password BEFORE the cache lookup so a denied username cannot be probed AND cannot be enumerated by timing the cache-hit response vs the cache-miss response. Applies to both empty_pw_case and unknown_user_case -- admins may want to constrain which empty-pw rows can pass-through too, not just unknown-user opt-in. Discovered by the security, integration, AND spec-vs-impl subagents during the PR #5810 deep review -- triple convergence on "dead variable".	1 month ago
Rene Cannao	c6839430e3	fix(passthrough-auth): unknown-user cache hit no longer clobbers state When a passthrough cache hit occurs for an unknown user (no row in mysql_users), PPHR_verify_password falls through to PPHR_5passwordTrue, which copies every routing / schema / connection-policy field from account_details onto the session: sess->default_hostgroup <- attr1.default_hostgroup sess->default_schema <- attr1.default_schema sess->schema_locked <- attr1.schema_locked sess->transaction_persistent <- attr1.transaction_persistent sess->session_fast_forward <- attr1.fast_forward ? PERMANENT : NONE sess->user_max_connections <- attr1.max_connections For unknown users, GloMyAuth->lookup returns a value-initialized account_details_t (all scalars zero, all pointers null). The previous code only mirrored default_hostgroup into account_details on cache hit -- the other fields were left at zero, silently overwriting the session-level defaults that the synthesis block above had set from globals. Net effect of the bug: - default_hostgroup got reset to 0 instead of staying at mysql-passthrough_default_hg - default_schema reset to NULL, ignoring mysql-passthrough_default_schema and mysql-default_schema - transaction_persistent reset to false (we set it to true in synthesis as a sensible default for an unknown user) Spec §3.5: "Routing/defaults for unknown users are re-derived from globals each connect". The fix mirrors ALL the synthesized fields into account_details on cache hit so PPHR_5passwordTrue's unconditional copy is now consistent with the synthesis, not a silent reset. The fields populated explicitly: default_hostgroup = mysql-passthrough_default_hg default_schema = mysql-passthrough_default_schema (or fallback) schema_locked = false transaction_persistent = true fast_forward = false max_connections = 0 (unlimited; honors global cap) use_ssl = false (session-level TLS is independent) Discovered by the auth-correctness, security, AND integration subagents during the PR #5810 deep review -- triple convergence on the same defect made this an obvious must-fix.	1 month ago
Rene Cannao	d4569ee8fa	fix(passthrough-auth): reject COM_CHANGE_USER for pass-through users Spec §5.4 promises that COM_CHANGE_USER targeting a pass-through- eligible user is rejected in Phase 1. The implementation never wired this rejection: process_pkt_COM_CHANGE_USER calls verify_user_pass directly (NOT PPHR_verify_password), so the new pass-through cache lookup / dispatch block never sees the request. For an empty-password row, the existing branch if (pass_len == 0 && strlen(password) == 0) { ret = true; } then grants passwordless CHANGE_USER -- the same §3.2 bypass that the previous commit fixed for the initial handshake path, now also present on the mid-session path. Add an explicit rejection ahead of the legacy branches in process_pkt_COM_CHANGE_USER: - master gate on (passthrough_auth_enabled) - empty-pw gate on (passthrough_auth_empty_password) - row exists with empty stored password - MySQL or SQLite session -> ret = false, generic auth failure, no information leak Phase 1 explicitly does not support driving the caching_sha2_password full-auth exchange from CHANGE_USER (the protocol-level state machine in PPHR_passthrough_init assumes a fresh client handshake and would corrupt a session that already has a bound backend connection). The rejection here is the documented escape valve: clients fall back to opening a fresh connection, which goes through the normal PPHR_verify_password / pass-through path and works as expected. Unknown-user case (password == NULL) already falls through to ret=false a few lines down via legacy code -- no new guard needed. Discovered by the integration and spec-vs-impl subagents during the PR #5810 deep review.	1 month ago
Rene Cannao	f80a5f933b	fix(passthrough-auth): reject empty-pw row for non-caching_sha2 plugins Spec §3.2 says: when mysql-passthrough_auth_enabled is on, a mysql_users row with password='' is treated ONLY as a pass-through signal -- it is no longer a passwordless-login marker. Before this fix the implementation only enforced that for caching_sha2_password clients: a mysql_native_password client connecting to the same row fell through the pass-through eligibility check (which is plugin- gated) and hit the existing PPHR_verify_password branch if (pass_len == 0 && strlen(password) == 0) { ret = true; } which silently granted passwordless login. The documented behavior change of §3.2 was therefore plugin-conditional and easy to bypass. Add a hard-reject branch ahead of the pass-through dispatch: when the master gate is on, the row's stored password is empty, and the client's plugin is NOT caching_sha2_password, set ret=false and return immediately. Same generic auth-failure disposition the client would get from any other rejection -- no information leak about whether the user exists. Only applies to empty_pw_case (admin-provisioned opt-in row). The unknown_user_case already cannot reach the passwordless branch because vars1.password == NULL routes through a different path. Discovered by the integration and spec-vs-impl subagents during the PR #5810 deep review.	1 month ago
Rene Cannao	3b09af50bf	feat(passthrough-auth): unknown-user dispatch path Extends the cache-lookup/dispatch block in PPHR_verify_password to cover the unknown-user case in addition to the empty-password row case (spec §3.1, §3.5). Eligibility split: empty_pw_case : vars1.password != NULL && strlen == 0 gated by passthrough_auth_empty_password unknown_user_case: vars1.password == NULL (user not in mysql_users) gated by passthrough_auth_unknown_users For the unknown-user case the session's routing/schema defaults are synthesized from globals before the cache lookup, since there's no mysql_users row to drive PPHR_5passwordTrue: default_hostgroup <- mysql-passthrough_default_hg default_schema (if NULL) <- mysql-passthrough_default_schema (falls back to mysql-default_schema) schema_locked <- false transaction_persistent <- true session_fast_forward <- NONE user_max_connections <- 0 (unlimited; honors global cap) These are re-derived each connect (spec §3.5), so changing mysql-passthrough_default_hg affects future logins immediately without requiring a cache flush. On cache hit, account_details.default_hostgroup is also populated to keep the post-verification path consistent. On cache miss the existing TLS gate runs, then PPHR_passthrough_init drives the backend probe through AUTHENTICATING_BACKEND_FOR_CLIENT.	1 month ago
Rene Cannao	2ff27f39cb	feat(passthrough-auth): TLS gating for pass-through Spec §7.1 / §7.4: when mysql-passthrough_auth_require_tls=true (default) and the client connection is not encrypted, refuse to dispatch pass-through. AuthMoreData{0x04} is never sent in this state so the client never gets prompted for its cleartext password over an unencrypted channel. Operationally this means the connection falls through to the existing rejection path (empty stored password + non-empty client password = auth failure), giving the client the same generic 'Access denied' it would see if pass-through were disabled entirely. The gate is bypassable only by either enabling TLS client-side or by setting mysql-passthrough_auth_require_tls=false. RSA-public-key support for non-TLS caching_sha2_password (also mentioned in §7.4) is deferred to Phase 2.	1 month ago
Rene Cannao	6f1c79a150	feat(passthrough-auth): PPHR_passthrough_init protocol helper Drives the caching_sha2_password full-auth exchange when ProxySQL doesn't yet have a password for an empty-password row and the in-memory cache also misses (spec §4.1, §5.2). switching_auth_stage == 0 (first call): send AuthMoreData{0x04} so the client emits cleartext set stage = 4, auth_in_progress = 1 switching_auth_stage == 5 (client replied with cleartext): stash the cleartext on MySQL_Data_Stream::passthrough_cleartext transition session to AUTHENTICATING_BACKEND_FOR_CLIENT (the session handler will then probe the backend) New field: MySQL_Data_Stream::passthrough_cleartext (char*, scrubbed+freed in the data-stream destructor) PPHR_verify_password now calls PPHR_passthrough_init on cache miss (empty-password row case only — the unknown-user case still needs the synthesize-defaults logic that lands with task #8). For builds where #8 hasn't landed yet, transitioning to AUTHENTICATING_BACKEND_FOR_CLIENT hits the defensive stub arm and fails the session cleanly; no client gets through. Cleartext is best-effort scrubbed (memset) before free so it does not linger in heap.	1 month ago
Rene Cannao	d31700e022	feat(passthrough-auth): consult cache in PPHR_verify_password (empty-pw) Inserts a cache lookup at the entry of PPHR_verify_password covering the empty-password row case (spec §8.2): if pass-through is enabled AND empty_password gate is enabled AND caching_sha2_password AND mysql session AND mysql_users row exists with password='' -> look up GloMyPTAuthCache for vars1.user -> on cache hit, replace vars1.password with the learned cleartext The rest of PPHR_verify_password then verifies as if mysql_users had stored a cleartext password, hitting the existing 'auth_plugin_id == AUTH_MYSQL_CACHING_SHA2_PASSWORD && password[0]!='*'' clear-text branch. TTL is read from mysql-passthrough_auth_cache_ttl_s; 0 means no expiry. Cache is empty in current builds (nothing populates it yet), so this branch is dead code until PPHR_passthrough_init / the AUTHENTICATING_BACKEND_FOR_CLIENT state handler land in the next commits. The unknown-user case (no row in mysql_users) also waits on those commits since it needs the dispatch logic, not just a lookup.	1 month ago
Rene Cannao	7824489fc9	fix(mysql): advertise CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA in server greeting ProxySQL already correctly parses the lenenc auth data format when clients send it in the handshake response (MySQL_Protocol.cpp:1708), but the server greeting packet never advertised the capability flag. Clients like Boost MySQL require this flag before they will even attempt a connection. Adding it to extended_capabilities makes ProxySQL compatible with such clients without any protocol behavior change. The existing test_greeting_capabilities-t test is updated to include the new flag in the baseline regression check. Closes: #4760	2 months ago
Wazir Ahmed	8d94919b22	fix: preserve EOF capability in enforced mode - Keep `CLIENT_DEPRECATE_EOF` enabled during frontend handshake when `session_track_variables=ENFORCED`. - Avoid unsafe mysql_error() calls in session-track TAP tests. Signed-off-by: Wazir Ahmed <wazir@proxysql.com>	2 months ago
Wazir Ahmed	885712c679	Merge branch 'v3.0' into session-track-system-variable	2 months ago
Rene Cannao	4e39f3bdc4	fix: parse caching_sha2_password rounds as hex (auth fails on rounds >= 10000) MySQL stores the rounds field of caching_sha2_password hashes ($A$<RRR>$<salt><hash>) as 3-char zero-padded uppercase hex of (rounds/1000). See sql/auth/sha2_password.cc: sprintf(rounds_str, "%03X", m_stored_digest_rounds) ProxySQL was parsing this field with stol(s, 10) (default base-10), which silently truncates at the first hex digit (A-F): 005 → 5 (5000 rounds, MySQL 8.0 default) ✓ matches base-16 009 → 9 (9000 rounds) ✓ matches base-16 00A → 0 (10000 rounds, stops at 'A') ✗ should be 10 010 → 10 (16000 rounds, decimal!) ✗ should be 16 01A → 1 (26000 rounds, stops at 'A') ✗ should be 26 The wrong rounds value is then fed into sha256_crypt_r() via "$5$rounds=<n*1000>$<salt>", producing a digest that does not match the stored hash, so verification fails with Access denied. Trigger: any MySQL backend with caching_sha2_password_digest_rounds >= 10000 (or any value whose hex encoding contains A-F). Surfaces in CI on the mysql95 dbdeployer image, where backend-generated hashes start with $A$00A$. The bug is latent on MySQL 8.0/8.4/9.0 with default rounds=5000 because "005" parses identically in base-10 and base-16. Fix: pass base=16 to stol() in both PPHR_verify_sha2() and PPHR_sha2full().	2 months ago
René Cannaò	82fadbc1f4	Merge pull request #5623 from sysown/v3.0-issue5621 Fix regression: restore upper-word capabilities dropped from greeting	2 months ago
Rene Cannao	4d251c80ec	Revert 'enable_client_session_tracking' variable; keep greeting fix Issue #5621 mis-diagnosed "CLIENT_SESSION_TRACKING missing from the greeting" as a long-standing configuration gap and proposed a new 'mysql-enable_client_session_tracking' variable analogous to 'mysql-enable_client_deprecate_eof'. On closer inspection this was in fact a regression introduced by commit `8c6a6444d` (zstd refactor), which dropped the hard-coded upper-word bits from the greeting. The right fix is simply to restore those hard-coded bits — commits `536c9d916` and `6b311b701` already do that via the 'extended_capabilities' local in 'generate_pkt_initial_handshake'. The new variable adds no value on top of that: the hard-coded bits cannot be disabled through 'mysql-server_capabilities' (which is OR-combined with the greeting), and there is no protocol hazard motivating a per-instance off-switch for CLIENT_SESSION_TRACKING, unlike CLIENT_DEPRECATE_EOF. Revert the variable (MySQL_Thread.h / proxysql_structs.h / MySQL_Thread.cpp / MySQL_Protocol.cpp) and restore CLIENT_SESSION_TRACKING to the 'extended_capabilities' literal, matching v3.0.6 exactly. Keep the test's doxygen / diag / baseline-check rewrite from the investigation — it's strictly better coverage and will catch any future regression of the hard-coded bits early. Test plan reduced to 2 scenarios (deprecate_eof on/off) since session_tracking is now unconditionally advertised.	2 months ago
Rene Cannao	174c5bda20	test: expand zstd_compression_level test with MySQL 8.4 C API and timing benchmark The existing test only verified admin variable behavior (default, range, independence). It did not prove that ZSTD compression was actually active on the wire. Two new test variants address this: MariaDB connector path (mysql-zstd_compression_level-t): - Tests 1-9: unchanged (variable defaults, range validation, independence) - Tests 10-11: use mysql CLI via execvp with --compression-algorithms=zstd and --zstd-compression-level={3,19}. Each call spawns a new process (= new connection). Verifies CONNECTION_ID() retrieval and large resultset transfer. Skipped if mysql CLI lacks zstd support. MySQL 8.4 connector path (mysql-zstd_compression_level_libmysql-t): - Tests 1-9: same as MariaDB path - Test 10: establishes a ZSTD connection using mysql_options( MYSQL_OPT_COMPRESSION_ALGORITHMS, "zstd") and prints mysql_thread_id() without running any query. - Test 11: timing benchmark proving compression is active. Creates a query rule (rule_id=1, cache_ttl=60000) to cache all SELECTs, then runs a 576-row resultset query 1000 times on a plain connection and 1000 times on a ZSTD level 22 connection. ZSTD level 22 is extremely CPU-intensive: observed 40122ms vs 858ms (46.7x ratio). A ratio >= 3x proves compression is really running on the client<->ProxySQL link. Other changes: - MySQL_Protocol.cpp: simplify redundant clamping to a simple cast (the variable is already validated at SET time) - Makefile: add build rule for _libmysql variant linking against MySQL 8.4 connector - groups.json: register _libmysql variant for mysql84/90/95-g1 - CLAUDE.md: update testing section with CI script usage and DO NOT list	2 months ago
Rene Cannao	6b311b7014	Restore greeting upper-word caps via local 'extended_capabilities' Previous commit (`536c9d916`) OR-ed the dropped upper-word bits into 'mysql_thread___server_capabilities', which made them leak into '(myds)->myconn->options.server_capabilities' — a behaviour delta vs. pre-8c6a6444d. Revert that and reinstate the original pattern: a local 'extended_capabilities' whose only consumer is 'upper_word'. Seed it with the hardcoded baseline (CLIENT_MULTI_, CLIENT_PLUGIN_AUTH, CLIENT_REMEMBER_OPTIONS) and fold in any other upper-word bits currently set in 'server_capabilities' (CLIENT_DEPRECATE_EOF, CLIENT_SESSION_TRACKING, CLIENT_ZSTD_COMPRESSION, ...) so the greeting stays in sync with the per-session / per-toggle state — preserving 8c6a6444d's zstd advertisement while restoring the #4023 baseline.	2 months ago
Rene Cannao	536c9d9169	Restore greeting upper-word capabilities dropped in `8c6a6444d` The zstd refactor in `8c6a6444d` replaced the per-greeting 'extended_capabilities' local with 'server_capabilities' derived from 'mysql_thread___server_capabilities'. As a side effect, the four upper-word bits the greeting used to hardcode were no longer advertised: CLIENT_MULTI_STATEMENTS CLIENT_MULTI_RESULTS CLIENT_PS_MULTI_RESULTS CLIENT_REMEMBER_OPTIONS OR these bits back into 'mysql_thread___server_capabilities' before the upper-word memcpy, matching what real MySQL 8.x advertises (see #4023). Also rewrite test_greeting_capabilities-t with doxygen documentation and step-by-step diag() tracing that decodes capability bitmasks to names, and reinstate the baseline-capability assertion that silently degraded when commit `6e1483f1f` tightened the caps_match overwrite into '&='. In 'PPHR_2', fold the CLIENT_SESSION_TRACKING enforcement into the shared two-step comment block for clarity.	2 months ago
Rene Cannao	1c3057ecf2	feat: use mysql-zstd_compression_level for zstd compression Replace mysql_thread___protocol_compression_level with mysql_thread___zstd_compression_level in both the handshake (MySQL_Protocol.cpp) and data stream (mysql_data_stream.cpp) zstd level selection paths, so the two compression algorithms can be configured independently.	2 months ago
Rene Cannao	c3532088d4	Add mysql-enable_client_session_tracking variable for client connections Introduce a new mysql global variable 'enable_client_session_tracking' (default: true) that controls whether CLIENT_SESSION_TRACKING is advertised to clients during handshake. This follows the same pattern as the existing 'enable_client_deprecate_eof' variable, allowing operators to disable session tracking capability on the client side independently of the server side. Closes #5621	3 months ago
Rene Cannao	f1826cf206	lint: fix reserved identifier in member variables Rename __active -> active_, __frontend -> frontend_, __backend -> backend_ in authentication and hostgroups classes to comply with C++ reserved identifier rules. Includes updates to: - MySQL_Authentication.hpp - ClickHouse_Authentication.hpp - PgSQL_Authentication.h - MySQL_HostGroups_Manager.h - Base_HostGroups_Manager.h - Corresponding .cpp files	3 months ago
René Cannaò	b94c855d4c	Merge branch 'v3.0' into advisory-fix-1 Signed-off-by: René Cannaò <rene@proxysql.com>	3 months ago
Rene Cannao	3d9a6e7ab4	Validate HandshakeResponse string fields	3 months ago
Rene Cannao	c9f627aac9	Validate COM_CHANGE_USER packet bounds	3 months ago
Rene Cannao	8c6a6444db	fix: support zstd compression in mysql84 TAP	3 months ago
copilot-swe-agent[bot]	33e125ef59	fix: tighten zstd handshake parsing Co-authored-by: renecannao <3645227+renecannao@users.noreply.github.com>	3 months ago
copilot-swe-agent[bot]	ec44a15058	feat: add mysql protocol zstd compression support Co-authored-by: renecannao <3645227+renecannao@users.noreply.github.com>	3 months ago
Wazir Ahmed	f0ac86c317	Enable session tracking based on server capabilities Signed-off-by: Wazir Ahmed <wazir@proxysql.com>	6 months ago
Javier Jaramago Fernández	64b16172c7	Change 'COM_STMT_EXECUTE' params length decoding According to MySQL protocol, variable length strings are encoded using length encoded integers. For reference, see: - https://dev.mysql.com/doc/dev/mysql-server/9.4.0/page_protocol_com_stmt_execute.html - https://dev.mysql.com/doc/dev/mysql-server/9.4.0/page_protocol_basic_dt_integers.html#a_protocol_type_int2 The protocol specifies that values greater than 2^24 (16777216) should be encoded using '0xFE + 8-byte integer'. Yet, in reality MySQL ignores the upper section of these 8-byte integers, treating them effectively like '4-bytes'. For the sake of compatibility this commit changes the decoding behavior for 'COM_STMT_EXECUTE' to match MySQL one. This different is subtle but important, since in practice MySQL itself doesn't use the '8 bytes' from the field. This means that connectors that are compatible with MySQL could find issues when sending these packets through ProxySQL (like NodeJS 'mysql2' connector which writes the 8-bytes as a 4-bytes duplication, motivating these changes), situation that could result in rejection due to malformed packet detection (or crashes/invalid handling in the worse case scenario). The previous decoding function is now renamed into 'mysql_decode_length_ll' to honor MySQL naming 'net_field_length_ll'. For now, this protocol change is limited to 'COM_STMT_EXECUTE'.	8 months ago
Javier Jaramago Fernández	e35973b226	Add boundary checks in 'MySQL_Protocol::get_binds_from_pkt' These checks should prevent crashes when packets are received holding invalid lengths in the processed params.	8 months ago
Rene Cannao	f803a1d419	Increase sid on caching_sha2 full authentication caching_sha2_password full authentication is a complex task that requires a lot of packets being sent and forth between client and server (ProxySQL in this case). Every packet needs to have an increased sequence ID (sid) according to protocol. ProxySQL was incorrectly forgetting to increase the sid when requesting a full authentication. For some clients this is not a problem, while other clients will consider the incorrect sid a serious issue and abort the connection. This commit ensures that sid is correctly increased when requesting caching_sha2_password full authentication.	8 months ago
Javier Jaramago Fernández	4304b995a3	Improve debug message with context dump (passwords) during auth handshake This message is dump with each call to 'process_pkt_handshake_response' printing the updated context. When the verbosity value for module 'debug_mysql_protocol' is >= 5, the stored and client supplied passwords will be dumped in HEX format, for values < 5, the passwords will be masked.	9 months ago
Javier Jaramago Fernández	f7c5756328	Fix losing database info on first logging for 'caching_sha2_password' The database specified in 'HandshakeResponse' was lost on the first logging when 'caching_sha2_password'. In this case a full-authentication was required, and this was the trigger for the context loss.	1 year ago
René Cannaò	ba95ad2382	In get_password() replaced a proxy_info() with proxy_debug()	1 year ago
Rahim Kanji	216b435463	Enshuring ProxySQL's stability when subjected to malformed packets	2 years ago
Rahim Kanji	967386d7d3	Added the SESSION_FORWARD_TYPE enum to define the type of session forwarding	2 years ago
Rahim Kanji	f99e806861	Fixed compilation error for all TEST* configurations	2 years ago
René Cannaò	cbf4628ea3	Merge remote-tracking branch 'proxysql27/v2.7' into v2.x_postgres_merge27_20240917	2 years ago
Javier Jaramago Fernández	ff8d8b1125	Fix invalid read-after-free for 'account_details.attributes' This ownership model needs to be revisited. After transferring the ownership of an 'account_details_t' field, it should be nullified.	2 years ago
Javier Jaramago Fernández	bbda0a86eb	Add initial impl for dual-password support	2 years ago
Javier Jaramago Fernández	851a8850bc	Fix regression on 'COM_CHANGE_USER' for 'mysql_native_password' - Closes #4589 Fixes handing of 'COM_CHANGE_USER' for 'mysql_native_password' when using hashed user passwords.	2 years ago
Javier Jaramago Fernández	8a93882d1d	Fix assert on COM_CHANGE_USER with hashed pass for 'caching_sha2_password' For now, we always reply with an auth failure until 'Auth Switch Support' is added for 'caching_sha2_password'.	2 years ago
Miro Stauder	b7258e965f	use local includes - openssl	2 years ago
Miro Stauder	7695c42534	use local include - openssl	2 years ago
René Cannaò	fde8ace076	Removed json.hpp from include files This seems to speedup compile time, and also lead to smaller binary	2 years ago

1 2 3 4 5 ...

360 Commits (docs/passthrough-auth-spec)