From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Robbie Harwood <rharwood(at)redhat(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: [PATCH v3] GSSAPI encryption support |
Date: | 2015-10-16 06:07:43 |
Message-ID: | CAMsr+YH0jamGmOM=mwziYQg=J-0XVp4BosPEv1n+UMaNMj4aMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 October 2015 at 01:07, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
> The short - and probably most important - answer is that no, I haven't
> tested it, and it would be difficult for me to do so quickly.
IIRC it's pretty easy to fire up AWS instances that're primary domain
controllers, and then join a Pg box to them with Kerberos. I realise
that's different to having the time and desire to do it, though.
> Looking at
> http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html
> suggests that SSPI follows a separate codepath from the GSS code;
> certainly it's a different auth request, which means it shouldn't
> trigger the encryption path.
It's a different auth request, but the handling in be-auth.c is
co-mingled to handle the cases:
* We're compiled with Kerberos, handling SSPI from Windows
* We're compiled with Kerberos, handling a GSSAPI request
* We're compiled with SSPI, and we're using Windows SSPI to handle a
GSSAPI auth request
* We're compiled with SSPI, and we're using it to handle a SSP client request
SSPI is a wrapper. For Windows Domain members it carries
GSSAPI/Kerberos data with the spnego extension. (For local loopback it
does NTLM, but you don't need to care about that).
> There is no reason that using GSSAPI from, e.g., MIT Kerberos for
> Windows, should not work here.
Except that *nobody* does it. The EDB installer builds Pg with SSPI,
and that's what the overwhelming majority of Windows users use.
Personally I don't care if this patch doesn't add support for GSSAPI
encryption for sspi connections, only that it doesn't break them.
> Even more broadly than that, GSSAPI is a
> RFC-standardized protocol with rigorously tested interop etc. etc.,
> though whether anyone outside of MIT cares about MIT Kerberos for
> Windows I have no idea.
It's maintained enough that AFAIK it works, and Pg supports compiling
with it. No idea if anyone tests it with Pg anymore.
> I think the important takeaway here is that I haven't actually changed
> how *authentication* works; these changes only affect GSSAPI
> post-authentication add encryption functions as defined by that
> specification. So if the authentication was working before, and the
> GSSAPI implementation is following RFC, I would hope that this would
> work still.
Hope so.
I'll put this on my "hope to test it at some stage" list, but I don't
have a prebuilt environment for it and have a lot to get ready for the
next CF, so it'll be a while...
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2015-10-16 06:12:08 | Re: proposal: PL/Pythonu - function ereport |
Previous Message | Kyotaro HORIGUCHI | 2015-10-16 05:37:47 | Re: Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied” |