Re: weird libpq GSSAPI comment

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robbie Harwood <rharwood(at)redhat(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: weird libpq GSSAPI comment
Date: 2020-01-06 21:03:22
Message-ID: 20200106210322.GJ3195@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Robbie Harwood (rharwood(at)redhat(dot)com) wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>
> > How about this?
> >
> > * If GSSAPI is enabled and we can reach a credential cache,
> > * set up a handle for it; if it's operating, just send a
> > * GSS startup message, instead of the SSL negotiation and
> > * regular startup message below.
>
> Due to the way postgres handled this historically, there are two ways
> GSSAPI can be used: for connection encryption, and for authentication
> only. We perform the same dance of sending a "request packet" for
> GSSAPI encryption as we do for TLS encryption. So I'd like us to be
> precise about which one we're talking about here (encryption).

Alright, that's fair.

> The GSSAPI idiom I should have used is "can acquire credentials" (i.e.,
> instead of "can reach a credential cache" in your proposal).

Ok.

> There's no such thing as a "GSS startup message". After negotiating
> GSSAPI/TLS encryption (or failing to do so), we send the same things in
> all cases, which includes negotiation of authentication mechanism if
> any. (Negotiating GSSAPI for authentication after negotiating GSSAPI
> for encryption will short-circuit rather than establishing a second
> context, if I remember right.)

Yes, you can see that around src/backend/libpq/auth.c:538 where we skip
straight to pg_GSS_checkauth() if we already have encryption up and
running, and if we don't then we go through pg_GSS_recvauth() (which
will eventually call pg_GSS_checkauth() too).

> I wonder if part of the confusion might be due to the synonyms we're
> using here for "in use". Things seem to be "got running", "set up",
> "operating", "negotiated", ... - maybe that's part of the barrier to
> understanding?

How about something like this?

* If GSSAPI Encryption is enabled, then call pg_GSS_have_cred_cache()
* which will return true if we can acquire credentials (and give us a
* handle to use in conn->gcred), and then send a packet to the server
* asking for GSSAPI Encryption (and skip past SSL negotiation and
* regular startup below).

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robbie Harwood 2020-01-06 21:21:30 Re: weird libpq GSSAPI comment
Previous Message Robert Haas 2020-01-06 20:56:55 Re: Removing pg_pltemplate and creating "trustable" extensions