Re: Proposal: Support custom authentication methods using hooks - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Proposal: Support custom authentication methods using hooks
Date
Msg-id 20220803202808.GE32653@tamriel.snowman.net
Whole thread Raw
In response to Re: Proposal: Support custom authentication methods using hooks  (samay sharma <smilingsamay@gmail.com>)
Responses Re: Proposal: Support custom authentication methods using hooks
List pgsql-hackers
Greetings,

* samay sharma (smilingsamay@gmail.com) wrote:
> On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion <jchampion@timescale.com>
> wrote:
> > [dev hat] That said, I plan to do some additional dev work on top of
> > this over the next couple of months. The ideal case would be to provide
> > a server-only extension that provides additional features to existing
> > clients in the wild (i.e. no client-side changes).
> >
> > I'm also interested in plugging an existing 3rd-party SASL library into
> > the client, which would help extensibility on that side.
>
> That would be interesting.

Again, server-side only is not interesting and not a direction that
makes sense to go in because it doesn't provide any way to have
trust established in both directions, which is what all modern
authentication methods do (certificates, kerberos, scram) and is what we
should expect from anything new in this space.  If anything, the other
auth methods should be ripped out entirely (password, md5, ldap, etc),
but certainly not used as a basis for new work or a place to try and add
new features, as they're all well known to have serious vulnerabilities.

As it specifically relates to SASL- if there's work to properly support
SASL for psql/libpq while linking to an external library which supports,
say, Kerberos through SASL, then sure, having that could work out well
and I wouldn't object to it, but I don't agree that we should have
dedicated SASL code which links to an external library on the server
side without any way to exercise it through libpq/psql, or vice-versa.

I also don't agree that this makes sense as an extension as we don't
have any way for extensions to make changes in libpq or psql, again
leading to the issue that it either can't be exercised or we create some
dependency on an external SASL library for libpq but object to having
that same dependency on the server side, which doesn't seem sensible to
me.  Requiring admins to jump through hoops to install an extension
where we have such a dependency on a library anyway doesn't make sense
either.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: optimize lookups in snapshot [sub]xip arrays
Next
From: Peter Geoghegan
Date:
Subject: Re: pg15b2: large objects lost on upgrade