7 Commits (docs/passthrough-auth-spec)

Author	SHA1	Message	Date
Rene Cannao	4ee7543f52	feat(passthrough-auth): mysql-passthrough_auth_failure_map_cap variable ... The failure-counter map size limit was a hardcoded FAILURE_MAP_HARD_CAP=100000 constant. The round-3 production- readiness review flagged this as Phase-2 work: operators on unusually-sized hosts (very large or very small memory budgets) have no way to tune it without rebuilding. Promote to an operator-tunable variable @c mysql-passthrough_auth_failure_map_cap with the same default (100000) and range [1000 .. 100M]. Threaded through: include/MySQL_Thread.h struct field include/proxysql_structs.h thread-local + extern lib/MySQL_Thread.cpp: - registered in mysql_thread_variables_names - init in init_variables - VariablesPointers_int entry with [1000 .. 100M] range - REFRESH_VARIABLE_INT in refresh_variables include/MySQL_Passthrough_Auth_Cache.h record_failure signature gains @c max_keys lib/MySQL_Passthrough_Auth_Cache.cpp uses parameter instead of the constant lib/MySQL_Session.cpp call site passes mysql_thread___... etc/proxysql.cnf operator-visible doc Default unchanged at 100000; existing deployments see no behavior change. Operators who need to tune it can do so via SET / LOAD MYSQL VARIABLES TO RUNTIME like any other passthrough variable. P2-B from the round-3 review of PR #5810.	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	c73d1be692	fix(passthrough-auth): pattern_lock to rwlock with reader fast-path ... username_allowed previously took a pthread_mutex_t for the entire compile-or-FullMatch operation. The compile is rare (only on pattern-string change) but the FullMatch fires for every probe- eligible connect. Worker threads serialized through this single mutex; under high connect rate this is contention on a global lock per connection. Switch pattern_lock to pthread_rwlock and split the access: Reader fast-path (the dominant case): rdlock; if cached pattern still matches; FullMatch under rdlock (re2::RE2::FullMatch on a const RE2 is documented thread-safe); unlock; return. Many readers can run concurrently. Writer slow-path (rare): pattern changed -> wrlock; re-check under wrlock (another thread may have compiled while we were upgrading); compile if still needed; FullMatch; unlock; return. Serialized only with other writers and any in-flight reader. The re-check after wrlock acquisition is critical: between the rdlock release and wrlock acquire, another thread might have already compiled the pattern we wanted. Without the re-check we'd allocate, free, and re-assign needlessly (and could lose data if the third thread used the soon-to-be-deleted RE2 instance). Header bumps the lock type to pthread_rwlock_t; init/destroy adjusted accordingly. Discovered by the fix-verification and new-code-quality subagents during the second deep review of PR #5810. Flagged as a performance risk under high connect rate.	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	d8525aeb0c	feat(passthrough-auth): per-user / per-IP rate limiting ... Spec §7.2: sliding-window failure counters on each side of the pass-through probe path. When either threshold is exceeded the session is rejected with the generic 'Access denied' ERR and the backend probe is NOT issued. Without these counters ProxySQL would become an open credential-stuffing amplifier against the configured backends. MySQL_Passthrough_Auth_Cache::would_lockout_user(user, max, window) MySQL_Passthrough_Auth_Cache::would_lockout_ip(ip, max, window) MySQL_Passthrough_Auth_Cache::record_failure(user, ip) The data structures (failures_by_user / failures_by_ip) hold monotonic timestamps in std::deque keyed by username / source IP. Lookups lazily prune timestamps older than the configured window; no background sweeper needed in Phase 1. A separate mutex (failure_lock) protects the maps, distinct from the cache rwlock, since these are write-mostly on the failure path. Configuration (spec §3.3): mysql-passthrough_auth_max_failures_per_user (default 3) mysql-passthrough_auth_max_failures_per_ip (default 10) mysql-passthrough_auth_failure_window_s (default 60) Rejects that happen before the probe (lockout hit, inflight cap, missing inputs) do NOT record a failure — we don't extend the lockout indefinitely. Only an actual backend rejection of the probe records a new failure.	1 month ago
Rene Cannao	cd44e3f68e	feat(passthrough-auth): global in-flight probe cap ... Spec §7.3: bound concurrent backend probes. When the configured cap (mysql-passthrough_auth_max_inflight_probes, default 100) is reached, additional sessions wishing to start a probe receive a generic 'Access denied' ERR instead. MySQL_Passthrough_Auth_Cache::try_acquire_inflight(max) — atomic compare-and-increment; returns false when at the cap. MySQL_Passthrough_Auth_Cache::release_inflight() — pair with every successful acquire. MySQL_Passthrough_Auth_Cache::inflight() — current count, for future stats exposure. In the session handler the slot is held by a local RAII guard so every return path (auth success, backend rejected, init failure, no healthy backend, ...) releases cleanly. Also bounds same-username races: even without a per-username lock, the global cap limits how many concurrent probes for the same user can fire. Minor duplicate probing is accepted as a v1 trade-off (spec §7.3).	1 month ago
Rene Cannao	4f4d5f3493	feat(passthrough-auth): scaffold MySQL_Passthrough_Auth_Cache ... First commit of the pass-through authentication implementation (spec: doc/internal/passthrough_authentication.md, PR #5810). Adds an in-memory cache class that will later hold credentials learned via pass-through authentication: - include/MySQL_Passthrough_Auth_Cache.h — class definition with lookup/insert/evict/clear/snapshot API and lazy TTL expiry on lookup - lib/MySQL_Passthrough_Auth_Cache.cpp — implementation using an unordered_map keyed by username and a pthread_rwlock - src/main.cpp — singleton GloMyPTAuthCache constructed in ProxySQL_Main_init_Auth_module() and destroyed during shutdown - lib/Makefile — link the new object No consumers yet; the cache is constructed empty and not touched by the auth path. Library and binary build cleanly.	1 month ago