public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: VASUKI M <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: Custom oauth validator options
Date: Fri, 16 Jan 2026 08:39:04 -0800
Message-ID: <CAOYmi+nKQ_7+pWSzw=rP2_T9UL=URHBsKq005BDeMmmC_=PV8g@mail.gmail.com> (raw)
In-Reply-To: <CAN4CZFMeTuH4uANV1bOox0d-1mycCnyghY49cL+E8PYZ4Y=0Kw@mail.gmail.com>
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>
On Fri, Jan 16, 2026 at 12:31 AM Zsolt Parragi
<[email protected]> 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
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Custom oauth validator options
In-Reply-To: <CAOYmi+nKQ_7+pWSzw=rP2_T9UL=URHBsKq005BDeMmmC_=PV8g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox