Re: dblink: Add SCRAM pass-through authentication

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: dblink: Add SCRAM pass-through authentication
Date: 2025-03-06 20:33:16
Message-ID: fcf66266-40f2-439f-9e91-4c111101d5d9@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.02.25 00:19, Jacob Champion wrote:
> These don't seem right to me. SCRAM passthrough should be considered
> as_part_ of the connstr/security checks, but I think it should not
> _bypass_ those checks. We have to enforce the use of the SCRAM
> credentials on the remote for safety, similarly to GSS delegation.
> (This might be a good place for `require_auth=scram-sha-256`?)
>
> I've attached a failing test to better illustrate what I mean.
>
> It looks like the postgres_fdw patch that landed also performs a
> bypass -- I think that may need an open item to fix? CC'd Peter.

AFAICT, in pgfdw_security_check(), if SCRAM has been used for the
outgoing server connection, then PQconnectionUsedPassword() is true, and
then this check should fail if no "password" parameter was given. That
check should be expanded to allow alternatively passing the SCRAM key
component parameters.

But that would mean the check is too restrictive, while you are
apparently claiming that the check is not restrictive enough?

(Also, this would appear to mean the current SCRAM pass-through code in
postgres_fdw should mostly not work, but the tests work, so I'm confused.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-03-06 20:49:20 Re: Refactoring postmaster's code to cleanup after child exit
Previous Message Robert Haas 2025-03-06 20:23:34 Re: making EXPLAIN extensible