Re: SSPI authentication - Mailing list pgsql-hackers

* Magnus Hagander (magnus@hagander.net) wrote:
> Stephen Frost wrote:
> > If both are made available then I think that'd work fine for us.  I'm
> > concerned that the windows builds wouldn't include a version of libpq w/
> > GSSAPI...
>
> The default build wouldn't. The binary build wouldn't. If you by GSSAPI
> mean MIT linking - SSPI does GSSAPI *authentication* just fine.

I don't think SSPI supports having seperate credential caches, a
different default realm, etc...
(and I'm not sure how you'd set them up even if it did).

> One reason is that bringing in and configuring the MIT libraries is a
> significant overhead.

Erm, isn't this what's done now?  Are we actually overloaded in some way
on the buildds?  Would this actually be a measurable reduction in the
overhead of the buildds?  I find this argument less than convincing
reasoning for dropping existing functionality...

> Nothing would prevent you from building your own DLL with Kerberos linking.

Except when it breaks because it's not being tested in the build
system... :/  I expect there are other such things in the same situation
but I'm rather unhappy that it's something which is actually going to
impact people (at the least me) as opposed to GNU readline on some
esoteric architecture.

> > If I was confident that we could easily build it ourselves
> > then I wouldn't care as much but, since I've never had to build libpq on
> > Windows before, I'm not sure what effort is involved or what tools are
> > required.  I'm also not thrilled by the prospect. :)
>
> It's not hard, at least if you use MSVC to build it. It's harder with
> MingW, but far from impossible.

MSVC would be a rather unhappy requirement.  Do we have buildds running
with MingW?  Settings up buildds is documented, etc, no?  I don't know
if I could dedicate a machine to it but at least if I can build my own
buildd setup using the scripts and whatnot it might not be too bad..

> > I have to admit that this does kind of make
> > me wish a bit for a 'libpq config file' even though I'm generally against
> > such things.  Having the same easy switch as we do w/ Mozilla would be
> > really nice.
>
> So what we'd need in that case is a new libpq connectionstring
> parameter. Which can be done, but it'd require that all frontends that
> use libpq add support for it - such as pgadmin. I'm not sure if the ODBC
> driver will support arbitrary arguments, otherwise that one needs it too.

If the ODBC driver doesn't support changes to the connectionstring (and
I think it does, actually), that'd probably be a sensible thing to add
anyway.  Having to have what's essentially a library-config option
handled by all the clients does kind of suck though.

> As I'm sure you can tell, I'm far from convinced this is a good idea ;-)

It's also not exactly unheard of.  I'm pretty sure what mozilla does is
basically just dlopen() the appropriate library.  I'm not sure if it's
even got an internal set of dlls which link to the sspi/gssapi dlls
explicitly.  If it does we might be able to swipe it.  Sorry for my lack
of familiarity, but does SSPI provide a GSSAPI identical to the MIT one?
For some reason I was thinking it did (hence why the dll magic just
works, but there could be more going on in those possibly) in which case
I'm not even sure you'd need the MIT stuff available to compile with
support for it?

> Anybody else want to comment on this?

I've always been rather unhappy at the apparent lack of user participation
on this list. :/  I don't mean to imply that I speak for the silent
majority, just that it's frustrating when trying to gauge the impact
of changes.
Thanks,
    Stephen