Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id t66lxwxgaxinug7zr4pgf72anhzkqwgrudmqnczgjdu4rv3ll5@jkcxvyvkgcqc
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER
List pgsql-hackers
Hi,

On 2025-04-07 15:59:19 +0200, Peter Eisentraut wrote:
> On 05.04.25 02:27, Jacob Champion wrote:
> > On Tue, Apr 1, 2025 at 3:40 PM Jacob Champion
> > <jacob.champion@enterprisedb.com> wrote:
> > > Maybe a better idea would be to ship an SONAME of
> > > `libpq-oauth.so.0.<major>`, without any symlinks, so that there's
> > > never any ambiguity about which module belongs with which libpq.
> > 
> > While I was looking into this I found that Debian's going to use the
> > existence of an SONAME to check other things, which I assume will make
> > Christoph's life harder. I have switched over to
> > 'libpq-oauth-<major>.so', without any SONAME or symlinks.
> 
> Yes, this is correct.  We want a shared module, not a shared library, in
> meson parlance.

It's not entirely obvious to me that we do want that.

There recently was a breakage of building with PG on macos with meson, due to
the meson folks implementing a feature request to move away from using
bundles, as
1) bundles apparently aren't supported on iOS
2) there apparently aren't any restrictions left that require using bundles,
   and there haven't been for a while.

They've now reverted these changes, due to the postgres build failures that
caused as well as recognizing they probably moved too fast, but the iOS
portion seems like it could be relevant for us?


Afaict this library doesn't have unresolved symbols, due to just linking to
libpq. So I don't think we really need this to be a shared module?


> But the installation directory of a shared module should not be directly
> libdir.

Agreed. However, it seems like relocatability would be much more important for
something like libpq than server modules... Particularly on windows it'll
often just be shipped alongside the executable - which won't work if we load
from pklibdir or such.


> I don't know whether we need an exports file for libpq-oauth.  The other
> shared modules don't provide an export file, and I'm not sure whether this
> is even supported for shared modules.  I guess it doesn't hurt?

It does seem just using PGDLLEXPORT would suffice here.


> The PKG_CONFIG_REQUIRES_PRIVATE setting in libpq-oauth/Makefile is
> meaningless and can be removed.
> 
> In fe-auth-oauth.c, I note that dlerror() is not necessarily thread-safe.

I sometimes really really hate posix.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate