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
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 |