From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: dblink: Add SCRAM pass-through authentication |
Date: | 2025-03-18 19:32:35 |
Message-ID: | bce9a483-2128-41af-9f73-e6b9df31c1ba@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.03.25 17:53, Jacob Champion wrote:
> On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut <peter(at)eisentraut(dot)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.
Yeah, I think option (2) is enough for now. If someone wants to enable
the kinds of things you describe, they can always come back and
implement option (1) later.
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2025-03-18 19:45:20 | Re: Simplify the logic a bit (src/bin/scripts/reindexdb.c) |
Previous Message | Peter Geoghegan | 2025-03-18 19:31:41 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |