On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut <pe...@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
