Re: Kerberos delegation support in libpq and postgres_fdw

Greetings,

* Stephen Frost (sfrost@snowman.net) wrote:
> * Michael Paquier (michael@paquier.xyz) wrote:
> > On Mon, Sep 19, 2022 at 02:05:39PM -0700, Jacob Champion wrote:
> > > It's not prevented, because a password is being used. In my tests I'm
> > > connecting as an unprivileged user.
> > >
> > > You're claiming that the middlebox shouldn't be doing this. If this new
> > > default behavior were the historical behavior, then I would have agreed.
> > > But the cat's already out of the bag on that, right? It's safe today.
> > > And if it's not safe today for some other reason, please share why, and
> > > maybe I can work on a patch to try to prevent people from doing it.
> >
> > Please note that this has been marked as returned with feedback in the
> > current CF, as this has remained unanswered for a bit more than three
> > weeks.
>
> There's some ongoing discussion about how to handle outbound connections
> from the server ending up picking up credentials from the server's
> environment (that really shouldn't be allowed unless specifically asked
> for..), that's ultimately an independent change from what this patch is
> doing.

That got committed, which is great, though it didn't go quite as far as
I had been hoping regarding dealing with outbound connections from the
server- perhaps we should make it clear at least for postgres_fdw that
it might be good for administrators to explicitly say which options are
allowed for a given user-map when it comes to how authentication is
done to the remote server?  Seems like mostly a documentation
improvement, I think?  Or should we have some special handling around
that option for postgres_fdw/dblink?

> Here's an updated version which does address Robert's concerns around
> having this disabled by default and having options on both the server
> and client side saying if it is to be enabled or not.  Also added to
> pg_stat_gssapi a field that indicates if credentials were proxied or not
> and made some other improvements and added additional regression tests
> to test out various combinations.

I've done some self-review and also reworked how the security checks are
done to be sure that we're not ending up pulling credentials from the
environment (with added regression tests to check for it too).  If
there's remaining concerns around that, please let me know.  Of course,
other review would be great also.  Presently though:

- Rebased up to today
- Requires explicitly being enabled on client and server
- Authentication to a remote server via dblink or postgres_fdw with
  GSSAPI requires that credentials were proxied by the client to the
  server, except if the superuser set 'password_required' to false on
  the postgres_fdw (which has lots of caveats around it in the
  documentation because it's inherently un-safe to do).
- Includes updated documentation
- Quite a few additional regression tests to check for unrelated
  credentials coming from the environment in either cases where
  credentials have been proxied and in cases where they haven't.
- Only changes to existing regression tests for dblink/postgres_fdw are
  in the error message wording updates.

Thanks!

Stephen