MIME-Version: 1.0
References: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
 <CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com>
 <CAN4CZFP_2fe2-18wUoXDZodV8suVe9o++pv=hP8KxxvWkmCx7A@mail.gmail.com>
 <CAOYmi+kMuA7t9ao6rWZ=5kn_Zmd7qtwOay_ocEBXwkzKWbefhQ@mail.gmail.com>
 <CAE2r8H439jg+e5gXJpNNMoroe4CfWauDRfUBZC_9NUNTOhqzBQ@mail.gmail.com>
 <CAN4CZFN9RMF_79kx75SkQZezd91DocUzz89bJeBJrMO=uNuG2w@mail.gmail.com>
 <CAOYmi+krPZDC8K+9z64M2EY9fELTKzLbqw8fD_wK=87YV+TBgw@mail.gmail.com>
 <CAN4CZFPvjAt+eZJd=Rxp=yXRjva8CpJ_BbnF=vQW6uXCqfrjEg@mail.gmail.com>
 <CAOYmi+nbCrvcE9wLQdNCgMwDbbi_UzGYrzfC54txmMBJ9KxO=Q@mail.gmail.com>
 <CAN4CZFNywvG59B+nBgD1_1fHE2uODBH3EcF_gwLmC7Y5U6Ru4Q@mail.gmail.com>
 <CAOYmi+=-OdzHMzqg9i8TwYvgKwE-vroj0d-9SqnRnwbz02SgTg@mail.gmail.com>
 <CAN4CZFPo1POb9fWMihTACFxE=xSxKEANHRkxN4YbMMN-0SML=w@mail.gmail.com>
 <CAOYmi+kVAiKf=WrnyzGxCmx-uu=arPE0=+Mf_AOhuTzkvCNC2w@mail.gmail.com> <CAN4CZFMeTuH4uANV1bOox0d-1mycCnyghY49cL+E8PYZ4Y=0Kw@mail.gmail.com>
In-Reply-To: <CAN4CZFMeTuH4uANV1bOox0d-1mycCnyghY49cL+E8PYZ4Y=0Kw@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 16 Jan 2026 08:39:04 -0800
Message-ID: <CAOYmi+nKQ_7+pWSzw=rP2_T9UL=URHBsKq005BDeMmmC_=PV8g@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: VASUKI M <vasukianand0119@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, david.g.johnston@gmail.com, 
	Robert Haas <robertmhaas@gmail.com>, myon@debian.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2BnKQ_7%2BpWSzw%3DrP2_T9UL%3DURHBsKq005BDeMmmC_%3DPV8g%40mail.gmail.com>
Precedence: bulk

On Fri, Jan 16, 2026 at 12:31=E2=80=AFAM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> Yes, I see that concern, but that's a bit trickier. To do that
> properly we have to validate the variables, including their values,
> not just their names. If we only validate the names, that doesn't
> guarantee anything.

Right. This goes back to your question upthread as to why I brought
session_preload_libraries into all this -- I thought
session_preload_libraries already had handling for this, but it
doesn't.

> Would it be a good idea for it to dlopen/dlclose libraries?

No, unfortunately.

> The
> requirements of dlclose are not that strict, I'm not sure if it could
> cause any issues.

Last I knew (which was a while back), unloading a shared library tree
is fraught with peril, especially when you add dependency diamonds and
static initializers. I seem to remember that Windows, C++, and OpenSSL
all have particular areas of pain. My guess is that people are going
to make mistakes, leave dangling references around, and then either
crash the postmaster or (worse) copy a crashable address space into
every new backend.

And that's before you get into hooks and GUCs and etc. We used to have
a _PG_fini() callback for modules. It was disabled a long time ago
[1], then recently entirely removed from the codebase.

> > I might be misunderstanding, but wouldn't that imply that DBAs could
> > now put every existing SIGHUP setting into HBA? That doesn't seem
> > good.
>
> Yes, that would mean that. I'm not saying that would be
> better/semantically correct, but technically it could also work,
> that's why I mentioned it.

Okay, but that wouldn't be a committable change.

> The main use of PGC_HBA in this patch is to
> add additional error reporting / separate what can be placed into
> pg_hba. I could argue both for this approach and the opposite where we
> allow other variables in pg_hba.

Not sure what you mean by this (maybe once I can really test the
patch, I'll see?), but the reason I suggested placing PGC_HBA right
after PGC_SIGHUP is this: any SU_BACKEND or below variable seems
logically appropriate to set per HBA line, if the DBA wants (they're
all per-session), and anything SIGHUP or above is inappropriate/unsafe
(they're per-cluster). Does your patch disable the former?

[checks] Ah, it does prohibit those. Why?

--Jacob

[1] https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03