Re: [PoC] Federated Authn/z with OAUTHBEARER

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: 2025-04-07 22:26:47
Message-ID: CAOYmi+kt5UvPOXXXT9w_nHBNgcqiTQWS2j=D9qJaewvmO4iaAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg <myon(at)debian(dot)org> wrote:
> Why is this module worse? (I guess the answer is internal data
> structures... but does it have to be worse?)

It doesn't have to be, in general, and the coupling surface is small
enough (libpq_append_conn_error) that we have a relatively easy path
toward decoupling it in the future. But for 18, I suspect no one will
be happy with me if I try to turn that inside out right this instant.
The goal was just to turn an internal implementation detail into a
delay-loaded internal implementation detail.

> Because pkglibdir would be something like /usr/lib/postgresql/17/lib,
> even when there is only one libpq5 package for all major server
> versions on Debian. So if you have postgresql-16 installed, you'd end
> up with
>
> /usr/lib/postgresql/16/{bin,lib} everything from PG 16
> /usr/lib/x86_64-linux-gnu/libpq* libpq5
> /usr/lib/postgresql/17/lib/libpq-oauth.so
>
> ... which is weird.

Weird, sure -- but it's correct, right? Because you have PG17's OAuth
flow installed.

If someone comes to the list with a flow bug in three years, and I ask
them what version they have installed, and they tell me "PG16, and
it's loading /usr/lib/aarch64-linux-gnu/libpq/libpq-oauth.so." That
won't be incredibly helpful IMHO.

> > [1] Future work ideas in this area include allowing other people to
> > compile their own loadable flow plugin, so that the utilities can use
> > it. (Only Device Authorization can be used by psql et al, for 18.) At
> > that point, developers will need a limited API to twiddle the
> > connection handle, and our builtin flow(s?) could use the same API.
> > But that's not work we can tackle for 18.
>
> Perhaps keep things simple for PG18 and choose a simple filename and
> location. If future extensions need something more elaborate, we can
> still switch later.

Sounds good. Any opinions from the gallery on what a "libpq plugin
subdirectory" in pkglibdir should be called? ("client", "modules",
"plugins"...?) Is there still a good reason to put any explicit
versioning into the filename if we do that?

Thanks,
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Hunter 2025-04-07 22:36:59 Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators
Previous Message Nathan Bossart 2025-04-07 22:17:03 Re: Horribly slow pg_upgrade performance with many Large Objects