On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> So the way I understand this is that the options are:
>
> (1) We add a libpq function like PQconnectionUsedScramKeys() in the
> style of PQconnectionUsedPassword() and call that function during the
> checks.
>
> (2) We make use_scram_passthrough=true imply require_auth=scram-sha-256.
> This is essentially a way to get the info from (1) out of libpq using
> existing facilities.
Right.
> But it would preempt certain setups that might
> otherwise work. (Which ones? Are they important?)
If the backend HBA later changes, to require delegated GSS or a
different type of password authentication, the user will have to unset
use_scram_passthrough (or ask the owner of the foreign server to unset
it). Whereas before they could just add a password to their user
mapping or enable delegation to move forward immediately.
I think this is probably not a serious limitation, in practice.
> Why can't we use PQconnectionUsedPassword()? What problems would that
> leave? The example test case that Jacob showed earlier involved the
> remote server using "trust". We don't want that, of course. But what
> we want to make sure is that some kind of authentication happened
> between postgres_fdw and the remote server. PQconnectionUsedPassword()
> does indicate that.
That test also added a "password" HBA case, where the correct password
got pulled from the environment instead of the connection string.
Making sure authentication happens is only one part -- we have to
ensure authentication takes place using the end user's credentials and
not the server's.
So since PQconnectionUsedPassword() can't differentiate between "I
used your SCRAM key" and "I used a password I found lying around on
disk", it's not strong enough for this check.
> (Or could we just stick in require_auth=!none to solve this problem once
> and for all?)
It solves the trust case nicely (and we should maybe consider it for a
future simplification?), but not the "wrong credentials were used"
case.
Thanks!
--Jacob
