Re: [PATCH v3] GSSAPI encryption support

On 16 October 2015 at 21:34, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
>> On 16 October 2015 at 01:07, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>> > 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:
>
> be-auth.c? You mean src/backend/libpq/auth.c?

Ahem. Yes.

Also, I was actually thinking of the libpq front-end code, as it turns
out. The backend's handling of each method is much better separated.

>> * We're compiled with Kerberos, handling SSPI from Windows
>> * We're compiled with Kerberos, handling a GSSAPI request
>
> Eh, *kerberos* was removed with 9.4.0. I'm guessing you mean GSSAPI
> above.

Yes, being sloppy.

> src/backend/libpq/auth.c and src/interfaces/libpq/fe-auth.c have pretty
> clearly independent paths for SSPI and GSSAPI

fe-auth.c doesn't. See pg_fe_sendauth(...)'s case AUTH_REQ_GSS: and
AUTH_REQ_SSPI:

Not what I call clearly independent. I've had to deal with that tangle
of joy a few times...

> and which is used
> (server-side) is based on what the auth method in pg_hba.conf is.

Yep, agreed there. I was thinking that the backend overlapped more,
like the frontend does.

> In a
> properly set up environment, the client could be using either, but it's
> not like we try to figure out (or care) which the client is using from
> the server's perspective.

Exactly. I want to make sure we still don't have to care.

> Now, if you set up GSSAPI on the client side and tell it to require
> encryption and you're using SSPI on the server side (or the other way
> around) it's not likely to work without changes to the SSPI code paths,
> which we should be looking at doing.

So long as setting up gssapi auth on the backend without requiring
encryption still works with sspi clients, like it did before, I'm
happy. My concern is avoiding a regression in what works, not
requiring that the new functionality be supported everywhere.

>> > 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.
>
> Apparently *somebody* uses MIT KfW

Yeah, I meant nobody uses it with Pg on Windows.

> I doubt anyone's tried building or running PG with GSSAPI under Windows
> though. I agree it'd be good to test and see and perhaps even the EDB
> installers could be changed to add support for it back in (not sure if
> Dave really wants to though as it was a bit of a pain..).

It's a lot of a pain, and not just because of maintenance. Kerberos on
Windows needs access to various innards that you don't need when just
using SSPI to delegate SSO to the OS. It's less secure, fiddly, and
annoying. At least it was last time I had to deal with it, when I was
working around some SSPI bugs in psqlODBC before landing up patching
them in the driver instead.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services