I traced this back to a problem in client.c, inside handle_auth_response. When we find a match from the query and parse it by seeing a 'D' packet, we set client->auth_user to the new entry. However, if not 'D' is seen, and we skip straight to 'C' and 'Z', the code sees the lack of a client->auth_user as an indication that the above failed. This is not true, however, as auth_user is already set (to the config auth_user value). Thus, getting no rows back from the auth_query lets one log in as the powerful auth_user user. Patch coming soon.
The text was updated successfully, but these errors were encountered:
Per mailing list report (http://comments.gmane.org/gmane.comp.db.postgresql.pgbouncer.general/1251), use of auth_user and auth_query works fine, until an invalid user is entered, in which case the login falls back to the auth_user.
I traced this back to a problem in client.c, inside handle_auth_response. When we find a match from the query and parse it by seeing a 'D' packet, we set client->auth_user to the new entry. However, if not 'D' is seen, and we skip straight to 'C' and 'Z', the code sees the lack of a client->auth_user as an indication that the above failed. This is not true, however, as auth_user is already set (to the config auth_user value). Thus, getting no rows back from the auth_query lets one log in as the powerful auth_user user. Patch coming soon.
The text was updated successfully, but these errors were encountered: