Re: SCRAM pass-through authentication for postgres_fdw

On Wed Jun 25, 2025 at 3:07 PM -03, Alexander Pyhalov wrote:
> Matheus Alcantara писал(а) 2025-06-25 14:36:
>> Hi, thanks for testing and reporting the issue!
>>
>> On 25/06/25 11:37, Alexander Pyhalov wrote:
>>> Hi.
>>> I've started to look at this feature and found an issue - MyProcPort
>>> can be not set if connection is initiated
>>> by some bgworker. (Internally we use one for statistics collection.)
>>> In other places (for example, in be_gssapi_get_delegation())
>>> there are checks that port is not NULL. Likely postgres_fdw and dblink
>>> should do something similar.
>>>
>>
>> In this case the bgworker is used to collect statistics for the fdw
>> tables? If that's the case, since we don't have the MyProcPort and the
>> scram keys, will it use the user and password configured on user
>> mapping
>> properties? If that's also the case I think that we may have a problem
>> because the goal of this feature is to avoid storing the password on
>> user mapping.
>>
>> Do you have steps to reproduce the issue?
>
> Hi. I've created a simple extension to reproduce an issue. Just put
> attached files to contrib and run make check.
> You'll see bgworker crash.
>

Thanks! I was able to reproduce the issue.

I've also made some other tests and your patch looks good, so +1.

I've also made some tests by using the use_scram_passthrough option on
foreign server and if a bgworker try to use a foreign table that has
this option associated with the foreign server the connection will fail
because we don't have the MyProcPort and the password. To make it work
the password is required on USER MAPPING options. I think that this
limitation should be documented, see patch attached.

--
Matheus Alcantara