-
Notifications
You must be signed in to change notification settings - Fork 4.1k
pgwire: verifying user passwords is too aggressive #36160
Copy link
Copy link
Closed
Labels
A-authenticationPertains to authn subsystemsPertains to authn subsystemsA-cc-enablementPertains to current CC production issues or short-term projectsPertains to current CC production issues or short-term projectsA-securityA-sql-pgwirepgwire protocol issues.pgwire protocol issues.C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-server-and-securityDB Server & SecurityDB Server & Security
Description
Metadata
Metadata
Assignees
Labels
A-authenticationPertains to authn subsystemsPertains to authn subsystemsA-cc-enablementPertains to current CC production issues or short-term projectsPertains to current CC production issues or short-term projectsA-securityA-sql-pgwirepgwire protocol issues.pgwire protocol issues.C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-server-and-securityDB Server & SecurityDB Server & Security
Every time a non-root pgwire conn is opened, we check the password's hash (or lack of password) by reading the users table. This seems very wasteful. A customer has seen these queries sometimes get stuck (although that was probably a symptom of other badness), they've caused goroutine leaks (addressed in #35776), so they're definitely generating some noise. Also, generally, we should be controlling traffic to system ranges as much as possible. Also, our tests generally use root requests, which don't do that query, so this is a source of difference between our benchmarks and client apps.
Checking these damn passwords over and over seems silly. We could cache the results per user per node for some time, and so decrease the cost of new connection storms considerably.
Don't really know who this falls under. @jordanlewis, you it?