Обсуждение: Future of krb5 authentication
Now that we have working GSSAPI authentication, I'd like to see the following done: * Deprecate krb5 authentication in 8.3. At least in documentation, possibly with a warning when loading pg_hba.conf? * Remove krb5 authenticatino completely in 8.4. The reasons for this is: * krb5 auth doesn't do anything that gssapi doesn't. * krb5 authentication doesn't follow a published standard. It follows API examples from MIT later copied by Heimdal, but there is no documented standard. * krb5 authentication operates directly on the socket and as such violates the libpq protocol. This means it's not protected by SSL if you have SSL on your connection, and that it may misbehave with async sockets. This was actually on the agenda when we first talked about doig gssapi, but now that we have it it's time to bring it up again... Comments? //Magnus
Magnus Hagander wrote: > Now that we have working GSSAPI authentication, I'd like to see the > following done: > > * Deprecate krb5 authentication in 8.3. At least in documentation, possibly > with a warning when loading pg_hba.conf? > * Remove krb5 authenticatino completely in 8.4. libpq would still work against older server versions, right? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Wed, Jul 18, 2007 at 11:45:19AM +0100, Heikki Linnakangas wrote: > Magnus Hagander wrote: > > Now that we have working GSSAPI authentication, I'd like to see the > > following done: > > > > * Deprecate krb5 authentication in 8.3. At least in documentation, possibly > > with a warning when loading pg_hba.conf? > > * Remove krb5 authenticatino completely in 8.4. > > libpq would still work against older server versions, right? Not once krb5 is removed. Assuming the older server version used krb5 auth. I want to remove it from both libpq and the server. (8.3 libpq would of course work with older versions, since it's only deprecated at that point) I guess a compromise would be to remove it from the server in 8.4 and libpq in 8.5 or so, if people think that it's a problem. But I think we definitly want to get it out of libpq as well eventually. //Magnus
Magnus Hagander wrote: >> libpq would still work against older server versions, right? > > Not once krb5 is removed. Assuming the older server version used krb5 auth. OK, well thats a problem. pgAdmin supports back to 7.3... /D
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote: > Magnus Hagander wrote: > >>libpq would still work against older server versions, right? > > > >Not once krb5 is removed. Assuming the older server version used krb5 auth. > > OK, well thats a problem. pgAdmin supports back to 7.3... You have a similar problem there already - 8.1 removed support for Kerberos 4, so if your 7.3 server is configged with krb4, you loose anyway. //Magnus
Magnus Hagander wrote: > On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote: >> Magnus Hagander wrote: >>>> libpq would still work against older server versions, right? >>> Not once krb5 is removed. Assuming the older server version used krb5 auth. >> OK, well thats a problem. pgAdmin supports back to 7.3... > > You have a similar problem there already - 8.1 removed support for Kerberos > 4, so if your 7.3 server is configged with krb4, you loose anyway. We never shipped krb4 support in any of our self contained binary distros (I'm not counting those which rely on external libpq packages). Regards, Dave
Magnus Hagander wrote: > On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote: >> Magnus Hagander wrote: >>>> libpq would still work against older server versions, right? >>> Not once krb5 is removed. Assuming the older server version used krb5 auth. >> OK, well thats a problem. pgAdmin supports back to 7.3... > > You have a similar problem there already - 8.1 removed support for Kerberos > 4, so if your 7.3 server is configged with krb4, you loose anyway. Let's be practical here. We're going to have support for both in libpq for at least one version anyway. What do we gain by removing that support in a later release? I think we should just keep it around until we have a pressing reason to remove it, say if it gets in the way of implementing some new feature. In the server, I think we could remove it sooner. But even there, is there a reason why we should? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Wed, Jul 18, 2007 at 12:16:49PM +0100, Heikki Linnakangas wrote: > Magnus Hagander wrote: > > On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote: > >> Magnus Hagander wrote: > >>>> libpq would still work against older server versions, right? > >>> Not once krb5 is removed. Assuming the older server version used krb5 auth. > >> OK, well thats a problem. pgAdmin supports back to 7.3... > > > > You have a similar problem there already - 8.1 removed support for Kerberos > > 4, so if your 7.3 server is configged with krb4, you loose anyway. > > Let's be practical here. We're going to have support for both in libpq > for at least one version anyway. What do we gain by removing that > support in a later release? I think we should just keep it around until > we have a pressing reason to remove it, say if it gets in the way of > implementing some new feature. > > In the server, I think we could remove it sooner. But even there, is > there a reason why we should? The main reasons would be to have less code to maintain, and to make life easier for packagers. For example, win32 would no longer need to ship the kerberos binaries in the package (and update it properly etc). But sure, we might leave it in there until there's a direct problem with it (other than the ones we already know). Can I still get my deprecation of it though? ;-) //Magnus
Magnus Hagander wrote: > But sure, we might leave it in there until there's a direct problem with it > (other than the ones we already know). Can I still get my deprecation of it > though? ;-) I'm not sure what the deprecation would mean in the client-side. You're going to need it if you want to connect to a server that uses it, there's no alternative. In the server, I don't see a problem with it. What would the deprecation mean, though? Mention in the docs that it's going to removed sometime in the future? A warning if you enable it? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Wed, Jul 18, 2007 at 12:26:28PM +0100, Heikki Linnakangas wrote: > Magnus Hagander wrote: > > But sure, we might leave it in there until there's a direct problem with it > > (other than the ones we already know). Can I still get my deprecation of it > > though? ;-) > > I'm not sure what the deprecation would mean in the client-side. You're > going to need it if you want to connect to a server that uses it, > there's no alternative. No, it would mean nothing on the client. > In the server, I don't see a problem with it. What would the deprecation > mean, though? Mention in the docs that it's going to removed sometime in > the future? A warning if you enable it? At least a warning in the docs. And possibly also a warning when you enable it, depending on what people thing is appropriate. //Magnus
Dave Page wrote: > Magnus Hagander wrote: >>> libpq would still work against older server versions, right? >> >> Not once krb5 is removed. Assuming the older server version used krb5 >> auth. > > OK, well thats a problem. pgAdmin supports back to 7.3... > > I think you need to put forward an alternative plan, then. Asking us to wait until your oldest version is 8.4 before we rip it out of libpq doesn't sound too good. cheers andrew
Andrew Dunstan wrote: > > > Dave Page wrote: >> Magnus Hagander wrote: >>>> libpq would still work against older server versions, right? >>> >>> Not once krb5 is removed. Assuming the older server version used krb5 >>> auth. >> >> OK, well thats a problem. pgAdmin supports back to 7.3... >> >> > > I think you need to put forward an alternative plan, then. Asking us to > wait until your oldest version is 8.4 before we rip it out of libpq > doesn't sound too good. pgAdmin was just one example. This prevents anyone with kerberos5 in a similar situation upgrading their client libraries - including users of the myriad of apps that use psqlODBC. Regards, Dave
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander: > The main reasons would be to have less code to maintain, I don't think the krb5 support has needed all that much maintenance in the last few years. > and to make life > easier for packagers. For example, win32 would no longer need to ship the > kerberos binaries in the package (and update it properly etc). Nobody is forcing anyone to ship anything anyway. > But sure, we might leave it in there until there's a direct problem with it > (other than the ones we already know). Can I still get my deprecation of it > though? ;-) You might want to inquire about that on -general. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Dave Page wrote: > Magnus Hagander wrote: >>> libpq would still work against older server versions, right? >> >> Not once krb5 is removed. Assuming the older server version used krb5 >> auth. > > OK, well thats a problem. pgAdmin supports back to 7.3... How many people actually use kerberos... How many people who are using kerberos are going to be running 7.3. 7.3 is no longer supported so by postgresql.org so who cares. Joshua D. Drake > > /D > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
Dave Page wrote: > Andrew Dunstan wrote: >> >> >> Dave Page wrote: >>> Magnus Hagander wrote: >>>>> libpq would still work against older server versions, right? >>>> >>>> Not once krb5 is removed. Assuming the older server version used >>>> krb5 auth. >>> >>> OK, well thats a problem. pgAdmin supports back to 7.3... >>> >>> >> >> I think you need to put forward an alternative plan, then. Asking us >> to wait until your oldest version is 8.4 before we rip it out of libpq >> doesn't sound too good. > > pgAdmin was just one example. This prevents anyone with kerberos5 in a > similar situation upgrading their client libraries - including users of > the myriad of apps that use psqlODBC. Who likely don't use kerberos. Joshua D. Drake > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate >
Joshua D. Drake wrote: >> pgAdmin was just one example. This prevents anyone with kerberos5 in a >> similar situation upgrading their client libraries - including users >> of the myriad of apps that use psqlODBC. > > Who likely don't use kerberos. Probably not in the majority of cases - but we have a large userbase these days, and a small percentage may still equate to a large number. I know at least two people that do use psqlODBC + Kerberos. Regards, Dave
Magnus Hagander <magnus@hagander.net> writes:
> But sure, we might leave it in there until there's a direct problem with it
> (other than the ones we already know). Can I still get my deprecation of it
> though? ;-)
In the krb4 case, we left it in there until there was very little
probability anyone was using it anymore, and AFAIR there was no
significant maintenance burden from that. I don't see a reason to be
harsher on the krb5 case.
The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive. That is going to cause tremendous
pain because there won't be any convenient upgrade path. Particularly
not for users of binary packages (RPMs etc) --- they'll be screwed
if their packager changes, and have no way to upgrade if he doesn't.
This needs to be fixed.
regards, tom lane
peter_e@gmx.net (Peter Eisentraut) writes: > Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander: >> The main reasons would be to have less code to maintain, > > I don't think the krb5 support has needed all that much maintenance in the > last few years. > >> and to make life >> easier for packagers. For example, win32 would no longer need to ship the >> kerberos binaries in the package (and update it properly etc). > > Nobody is forcing anyone to ship anything anyway. But on the other hand, if support for something gets "ripped out," that pretty much forces packagers to NOT ship it anymore. So it's not totally symmetrical... >> But sure, we might leave it in there until there's a direct problem with it >> (other than the ones we already know). Can I still get my deprecation of it >> though? ;-) > > You might want to inquire about that on -general. Good idea... -- let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];; http://www3.sympatico.ca/cbbrowne/internet.html "This must be Thursday. I never could get the hang of Thursdays." - Arthur Dent
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > But sure, we might leave it in there until there's a direct problem with it > > (other than the ones we already know). Can I still get my deprecation of it > > though? ;-) > > In the krb4 case, we left it in there until there was very little > probability anyone was using it anymore, and AFAIR there was no > significant maintenance burden from that. I don't see a reason to be > harsher on the krb5 case. > > The real problem in my mind is this business of the gssapi and krb5 > support being mutually exclusive. That is going to cause tremendous > pain because there won't be any convenient upgrade path. Particularly > not for users of binary packages (RPMs etc) --- they'll be screwed > if their packager changes, and have no way to upgrade if he doesn't. > This needs to be fixed. Non, GSSAPI and krb5 are *not* mutually exclusive. SSPI and GSSAPI are mutually exclusive. You can use krb5 and GSSAPI or krb5 and SSPI just fine. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
>> This needs to be fixed.
> Non, GSSAPI and krb5 are *not* mutually exclusive.
> SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
regards, tom lane
Joshua D. Drake wrote: > Dave Page wrote: >> Andrew Dunstan wrote: >>> >>> >>> Dave Page wrote: >>>> Magnus Hagander wrote: >>>>>> libpq would still work against older server versions, right? >>>>> >>>>> Not once krb5 is removed. Assuming the older server version used >>>>> krb5 auth. >>>> >>>> OK, well thats a problem. pgAdmin supports back to 7.3... >>>> >>>> >>> >>> I think you need to put forward an alternative plan, then. Asking us >>> to wait until your oldest version is 8.4 before we rip it out of >>> libpq doesn't sound too good. >> >> pgAdmin was just one example. This prevents anyone with kerberos5 in a >> similar situation upgrading their client libraries - including users >> of the myriad of apps that use psqlODBC. > > Who likely don't use kerberos. I would also note that Magnus's proposal means that krb5 won't be removed for *at least* 2 years. I think that is plenty of time for an EOL cycle on a feature. Joshua D. Drake > > Joshua D. Drake > >> >> Regards, Dave >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: You can help support the PostgreSQL project by donating at >> >> http://www.postgresql.org/about/donate >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > The real problem in my mind is this business of the gssapi and krb5 > support being mutually exclusive. Oh, I didn't catch that. That's wrong anyways, there could be multiple applications on the same machine, some of which use krb4 and some which use gssapi. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote: >>> This needs to be fixed. > >> Non, GSSAPI and krb5 are *not* mutually exclusive. > >> SSPI and GSSAPI are mutually exclusive. > > Color me confused then. What's the difference? SSPI is a Windows-only implementation of the GSSAPI protocol, that has a different API. GSSAPI works on Unix and on Windows (but only with addon libraries, such as MIT (unix or win) or Heimdal (unix only)). The confusion probably comes from that GSSAPI is both a protocol (supported by SSPI as well) and an API (not supported by SSPI). Now, SSPI integrates with Active Directory, so it doesn't work if you don't want to join your workstation to the Kerberos realm. Or as in Stephens case, you want to be *both* on the Active Directory and in a non-trusted Unix Kerberos realm. But we're talking two different issues. Deprecating/removing krb5 is a different thing from having GSSAPI and SSPI mutually exclusive or not. //Magnus
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
> >> This needs to be fixed.
>
> > Non, GSSAPI and krb5 are *not* mutually exclusive.
>
> > SSPI and GSSAPI are mutually exclusive.
>
> Color me confused then. What's the difference?
GSSAPI is the MIT libraries, SSPI is the Windows library, but there's no
way to indicate to libpq which to use and they share some of the same
code paths with minor adjustments for each done at compile-time (aiui
anyway, Magnus can provide a clearer answer on this).
The feeling was that because there's no way to indicate to libpq which
to use except through the connectionstring and that most people would
want SSPI instead and that krb5 support is going to be removed that we
could just support either SSPI or GSSAPI (not both).
My feeling is that if we're going to continue to support krb5 *anyway*
(which I don't disagree with, honestly) then the GSSAPI stuff is going
to be required for the build *regardless* and therefore it makes sense
to support both in libpq rather than making them mutually exclusive.
Supporting it using a connectionstring option would be sufficient, imv,
though downstream utilities that don't let you modify the
connectionstring directly would have to add support for it (I'm of the
opinion that such things should be changed to allow a connectionstring
option, or at least an append to it, but perhaps there's some reason
that's a problem for some).
GSSAPI and SSPI are not, themselves, mutually exclusive. They're just
being made that way by the libpq code that's been proposed. Mozilla
handles doing both just fine and you flip between them using an option
in their 'about:config' screen.
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
> But we're talking two different issues. Deprecating/removing krb5 is a
> different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I disagree... If we need the MIT
headers/libraries around to support krb5 anyway then I don't feel the
fact that you can do SSPI w/o those headers/libraries to be a case for
not supporting GSSAPI on Windows, we need them anyway...
Thanks,
Stephen
* Dave Page (dpage@postgresql.org) wrote:
> Probably not in the majority of cases - but we have a large userbase these
> days, and a small percentage may still equate to a large number. I know at
> least two people that do use psqlODBC + Kerberos.
I certainly use it alot! Of course, we'll move to GSSAPI, assuming
that's not too difficult for us to do under Windows...
Thanks,
Stephen
* Joshua D. Drake (jd@commandprompt.com) wrote:
>> OK, well thats a problem. pgAdmin supports back to 7.3...
>
> How many people actually use kerberos... How many people who are using
> kerberos are going to be running 7.3. 7.3 is no longer supported so by
> postgresql.org so who cares.
AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
digs at what is really a very large userbase. Perhaps they're not all
running 7.3 but the implication that there's a small number of people
using Kerberos is just amazingly far off.
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> But we're talking two different issues. Deprecating/removing krb5 is a >> different thing from having GSSAPI and SSPI mutually exclusive or not. > > To the extent that keeping krb5 around implies a much lower burden on > GSSAPI support under Windows, I disagree... If we need the MIT > headers/libraries around to support krb5 anyway then I don't feel the > fact that you can do SSPI w/o those headers/libraries to be a case for > not supporting GSSAPI on Windows, we need them anyway... I was talking from a technical perspective, not a maintenance one. Your argument is at least party valid - though Dave has reported major issues due to the gssapi library changing between versions. But those are solvable. The maintenance part of me suggesting getting rid of krb5 is the smallest one. It being a non-standard protocol is more important, and the fact that the exchange breaks the libpq protocol and is not protected by SSL is the big reason. But none of those more important reasons speak for removing krb5 - just deprecating it. So I'm fine with doing that. (and again, the SSPI vs GSSAPI on win32 discussion is a different one) //Magnus
Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Magnus Hagander <magnus@hagander.net> writes: >>> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote: >>>> This needs to be fixed. >>> Non, GSSAPI and krb5 are *not* mutually exclusive. >>> SSPI and GSSAPI are mutually exclusive. >> Color me confused then. What's the difference? > > GSSAPI is the MIT libraries, SSPI is the Windows library, but there's no > way to indicate to libpq which to use and they share some of the same > code paths with minor adjustments for each done at compile-time (aiui > anyway, Magnus can provide a clearer answer on this). > Certainly not "just minor adjustments", since we need to do dynamic loading and checking for the functions. That's the big one, which will certainly increase the required code a lot. The part about letting the client specify how is probably fairly easy, if we can figure out a good one. (I personally think we've clearly shown that using the connectionstring is not a good enough way to do it) //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> The maintenance part of me suggesting getting rid of krb5 is the
> smallest one. It being a non-standard protocol is more important, and
> the fact that the exchange breaks the libpq protocol and is not
> protected by SSL is the big reason.
Erm, it doesn't need to be protected by SSL? Breaking the libpq
protocol does kind of suck. I assume you're not requiring SSL for the
GSSAPI stuff...
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
> Certainly not "just minor adjustments", since we need to do dynamic
> loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading and function checking?
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> The maintenance part of me suggesting getting rid of krb5 is the >> smallest one. It being a non-standard protocol is more important, and >> the fact that the exchange breaks the libpq protocol and is not >> protected by SSL is the big reason. > > Erm, it doesn't need to be protected by SSL? Breaking the libpq > protocol does kind of suck. I assume you're not requiring SSL for the > GSSAPI stuff... No, no requirement. But you would certainly expect it to use it if you have SSL on the connection. //Magnus
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> Certainly not "just minor adjustments", since we need to do dynamic >> loading and checking for the functions. That's the big one, which will > > If we're supporting krb5 anyway, and shipping the bits that go along > with that, do we need to do dynamic loading and function checking? Eh, good point. I got confused, it seems :-) Scratch that, then - we're back to finding a good way to specify it. //Magnus
Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
>>> OK, well thats a problem. pgAdmin supports back to 7.3...
>> How many people actually use kerberos... How many people who are using
>> kerberos are going to be running 7.3. 7.3 is no longer supported so by
>> postgresql.org so who cares.
>
> AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
> digs at what is really a very large userbase. Perhaps they're not all
> running 7.3 but the implication that there's a small number of people
> using Kerberos is just amazingly far off.
*cough* , compared to the number of installations *not* using kerberos
it is amazing that you would make such a far off correlation.
Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
* Magnus Hagander (magnus@hagander.net) wrote:
> No, no requirement. But you would certainly expect it to use it if you
> have SSL on the connection.
Uhh, perhaps, but my recollection is that it's generally *not* done that
way in other things.. Honestly, it doesn't matter to me, just wanted to
clear up the implication.
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
> Stephen Frost wrote:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> >> Certainly not "just minor adjustments", since we need to do dynamic
> >> loading and checking for the functions. That's the big one, which will
> >
> > If we're supporting krb5 anyway, and shipping the bits that go along
> > with that, do we need to do dynamic loading and function checking?
>
> Eh, good point. I got confused, it seems :-) Scratch that, then - we're
> back to finding a good way to specify it.
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have to be for sspi since it's the default), but since we're going
to keep krb5 support around for a bit there's time for those
applications to catch up without breaking things explicitly for people
migrating to 8.3.
I'd also use that as an opportunity to encourage applications to expose
the connectionstring to users as there may be things like this in the
future where it's purely a library thing and the application doesn't
have to know about it- except for the connectionstring.
Thanks,
Stephen
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Stephen Frost wrote:
>> * Joshua D. Drake (jd@commandprompt.com) wrote:
>>> How many people actually use kerberos... How many people who are using
>>> kerberos are going to be running 7.3. 7.3 is no longer supported so by
>>> postgresql.org so who cares.
>> AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
>> digs at what is really a very large userbase. Perhaps they're not all
>> running 7.3 but the implication that there's a small number of people
>> using Kerberos is just amazingly far off.
>
> *cough* , compared to the number of installations *not* using kerberos it
> is amazing that you would make such a far off correlation.
Oh, yea, and every place that uses Active Directory ..
> Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
> general.
I was referring to your first question, which, in my view, is the more
appropriate one *anyway*. At least if you have a "PostgreSQL is going
to dominate the WORLD!" point of view, as I do. :)
Thanks,
Stephen
Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> Oh, yea, and every place that uses Active Directory ..
>
>> Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
>> general.
>
> I was referring to your first question, which, in my view, is the more
> appropriate one *anyway*. At least if you have a "PostgreSQL is going
> to dominate the WORLD!" point of view, as I do. :)
Of course I do. I am just a realist and know that isn't going to happen
on Win32 ;)
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> Stephen Frost wrote: >>> * Magnus Hagander (magnus@hagander.net) wrote: >>>> Certainly not "just minor adjustments", since we need to do dynamic >>>> loading and checking for the functions. That's the big one, which will >>> If we're supporting krb5 anyway, and shipping the bits that go along >>> with that, do we need to do dynamic loading and function checking? >> Eh, good point. I got confused, it seems :-) Scratch that, then - we're >> back to finding a good way to specify it. > > Honestly, for now I'm happy w/ it being a connectionstring option. It > seems the most appropriate place for it to go. That does mean that > applications may need to be modified to support gssapi (where they might > not have to be for sspi since it's the default), but since we're going > to keep krb5 support around for a bit there's time for those > applications to catch up without breaking things explicitly for people > migrating to 8.3. Well, since you're the only one who've asked for the feature, I guess that's good enough for me unless someone else complains. If you have a good suggestion for a name for it, let me know, otherwise I'll just cook something up. BTW, I have working SSPI server code running on Windows now as well, giving the full Active Directory integration in the windows postgresql. It's far from perfect yet, needs a bunch of cleanup, but it works. (This is SSPI, of course) //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> Well, since you're the only one who've asked for the feature, I guess
> that's good enough for me unless someone else complains. If you have a
> good suggestion for a name for it, let me know, otherwise I'll just cook
> something up.
Mozilla uses 'gsslib', that would work for me.
ie:
gsslib=gss
gsslib=sspi
Also, thanks!
> BTW, I have working SSPI server code running on Windows now as well,
> giving the full Active Directory integration in the windows postgresql.
> It's far from perfect yet, needs a bunch of cleanup, but it works. (This
> is SSPI, of course)
Awesome! Very exciting. :)
Thanks,
Stephen
Stephen Frost wrote: > Honestly, for now I'm happy w/ it being a connectionstring option. It > seems the most appropriate place for it to go. That does mean that > applications may need to be modified to support gssapi (where they might > not have to be for sspi since it's the default), but since we're going > to keep krb5 support around for a bit there's time for those > applications to catch up without breaking things explicitly for people > migrating to 8.3. Isn't it possible to open the socket, try GSSAPI handshaking with protocol, and fall back to krb5 protocol if that fails? If that's not possible, how about handling it like we handle postgres protocol 3 vs 2? Connect using GSSAPI first, and if that fails, retry with krb5. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > Stephen Frost wrote: >> Honestly, for now I'm happy w/ it being a connectionstring option. It >> seems the most appropriate place for it to go. That does mean that >> applications may need to be modified to support gssapi (where they might >> not have to be for sspi since it's the default), but since we're going >> to keep krb5 support around for a bit there's time for those >> applications to catch up without breaking things explicitly for people >> migrating to 8.3. > > Isn't it possible to open the socket, try GSSAPI handshaking with > protocol, and fall back to krb5 protocol if that fails? If that's not > possible, how about handling it like we handle postgres protocol 3 vs 2? > Connect using GSSAPI first, and if that fails, retry with krb5. The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI. The wire protocol is the same for them. It's a matter of which *client library* should be used to produce the packets that go over the network. //Magnus
Magnus Hagander wrote: > Heikki Linnakangas wrote: >> Stephen Frost wrote: >>> Honestly, for now I'm happy w/ it being a connectionstring option. It >>> seems the most appropriate place for it to go. That does mean that >>> applications may need to be modified to support gssapi (where they might >>> not have to be for sspi since it's the default), but since we're going >>> to keep krb5 support around for a bit there's time for those >>> applications to catch up without breaking things explicitly for people >>> migrating to 8.3. >> Isn't it possible to open the socket, try GSSAPI handshaking with >> protocol, and fall back to krb5 protocol if that fails? If that's not >> possible, how about handling it like we handle postgres protocol 3 vs 2? >> Connect using GSSAPI first, and if that fails, retry with krb5. > > The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI. > > The wire protocol is the same for them. It's a matter of which *client > library* should be used to produce the packets that go over the network. Uh, this is really confusing. Let's see if I got this right. So we're talking about two orthogonal changes here: 1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3 server and libpq will use the GSSAPI wire protocol by default, with support for krb5 protocol when speaking with older versions. 2. In 8.2 and below, we used the GSSAPI library on all platforms. 8.3 adds support for Microsoft's SSPI interface on Windows. On Windows, why would you need GSSAPI, if SSPI comes with the operation system? What's the difference between the libraries? Can you try SSPI first, and fall back to GSSAPI? Can you do <= 8.2 style krb5 authentication with the SSPI library? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
* Heikki Linnakangas (heikki@enterprisedb.com) wrote:
> Uh, this is really confusing. Let's see if I got this right. So we're
> talking about two orthogonal changes here:
It is kinda confusing. :)
> 1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3
> server and libpq will use the GSSAPI wire protocol by default, with
> support for krb5 protocol when speaking with older versions.
Well, I think it'll depend on what's configured, no? Doesn't the libpq
protocol say back to the user "this is what I want to use" or similar?
The impression I got was more along the lines of- we'll have another
option in pg_hba.conf for 'gssapi', distinct from 'krb5' and either
could be used. Might have misunderstood tho.
> 2. In 8.2 and below, we used the GSSAPI library on all platforms. 8.3
> adds support for Microsoft's SSPI interface on Windows.
No.. We used the MIT Krb5 library. This is a change to use the GSSAPI
library (also from MIT and part of their Kerberos distribution, so it's
a tad confusing) on Unix by default and compile in support for it under
Windows as well.
> On Windows, why would you need GSSAPI, if SSPI comes with the operation
> system? What's the difference between the libraries? Can you try SSPI
> first, and fall back to GSSAPI?
You can't really 'fall back' without creating alot of noise in the logs
and whatnot. Also, it could try to do things that don't make any sense.
The reason to support both is that they have, essentially, different
feature sets.
> Can you do <= 8.2 style krb5 authentication with the SSPI library?
No, at least from a user-interface standpoint and I think also the
wireline protocol is different...
Thanks,
Stephen
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > Magnus Hagander wrote: > >> The wire protocol is the same for them. It's a matter of which *client >> library* should be used to produce the packets that go over the network. >... > On Windows, why would you need GSSAPI, if SSPI comes with the operation > system? What's the difference between the libraries? Can you try SSPI > first, and fall back to GSSAPI? Am I right in thinking that while the client<->postgres protocol may be the same the actual authentication tokens are different? That is, if you have a Windows Active Directory server then using SSPI will use your Windows credentials obtained from that server to log you in whereas if you used the MIT GSSAPI library it would try to use your Kerberos tickets for which it would look elsewhere? What confuses me here is that I don't understand how this relates to applications. You keep talking about using the connection string which may be appropriate for a user-oriented application like psql. But in the general case surely the application needs to be able to control the authentication process and be able to provide credentials of its choice? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Magnus Hagander <magnus@hagander.net> writes:
> The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI.
> The wire protocol is the same for them. It's a matter of which *client
> library* should be used to produce the packets that go over the network.
Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server? If there's no interoperability issues then I
agree that a configure-time choice is sufficient for selecting which
library to use.
regards, tom lane
* Gregory Stark (stark@enterprisedb.com) wrote:
> Am I right in thinking that while the client<->postgres protocol may be the
> same the actual authentication tokens are different? That is, if you have a
> Windows Active Directory server then using SSPI will use your Windows
> credentials obtained from that server to log you in whereas if you used the
> MIT GSSAPI library it would try to use your Kerberos tickets for which it would
> look elsewhere?
This *can* be true, and in fact is *exactly* what I do. The MIT client
comes with an option (enabled by default actually) to sync up the MIT
ticket cache with the SSPI one though.
> What confuses me here is that I don't understand how this relates to
> applications. You keep talking about using the connection string which may be
> appropriate for a user-oriented application like psql. But in the general case
> surely the application needs to be able to control the authentication process
> and be able to provide credentials of its choice?
We're talking about user-oriented applications... Specifically things
like psql and Postgres ODBC, which use user's credentials to connect to
the database and don't have their own credentials...
Thanks,
Stephen
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Oh, they're fully interchangeable at the wire level? Is this true both
> with respect to the PG client/backend protocol and the protocol to the
> authentication server?
I believe that's the case, yes.
> If there's no interoperability issues then I
> agree that a configure-time choice is sufficient for selecting which
> library to use.
In general I agree, but I'd like to see builds for Windows which support
them and I'm not sure that'll happen quite as regularly. :/
Aside from that issue though, if we're going to continue krb5 support
(which I'd encourage unless we have some reason to stop) and it's not
too much effort (I get the impression it's not) to support both
concurrently, I'd really appreciate it. :) I'm not aware of any 'funny
business' which would be involved in supporting them both at the same
time, and I believe Magnus is working on it.
Thanks,
Stephen
On Wed, Jul 18, 2007 at 06:01:33PM -0400, Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > Oh, they're fully interchangeable at the wire level? Is this true both > > with respect to the PG client/backend protocol and the protocol to the > > authentication server? > > I believe that's the case, yes. It is, as long as you use Kerberos auth. It's of course not if you use SSPI with NTLM, but that's not surprising. > > If there's no interoperability issues then I > > agree that a configure-time choice is sufficient for selecting which > > library to use. > > In general I agree, but I'd like to see builds for Windows which support > them and I'm not sure that'll happen quite as regularly. :/ Well, again, that's fairly easy to do by setting up a buildfarm member. > Aside from that issue though, if we're going to continue krb5 support > (which I'd encourage unless we have some reason to stop) and it's not > too much effort (I get the impression it's not) to support both > concurrently, I'd really appreciate it. :) I'm not aware of any 'funny > business' which would be involved in supporting them both at the same > time, and I believe Magnus is working on it. That is the point. It's going to be some more code, but that code will be fairly trivial. That's for client. How should we go about doing it on the server side? Perhaps just add the ability to specify sspi as authentication method, to differentiate it from gss? //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> That's for client. How should we go about doing it on the server side?
> Perhaps just add the ability to specify sspi as authentication method, to
> differentiate it from gss?
That certainly works for me, and makes sense to me.
Thanks!
Stephen
On Thu, Jul 19, 2007 at 06:38:08AM -0400, Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: > > That's for client. How should we go about doing it on the server side? > > Perhaps just add the ability to specify sspi as authentication method, to > > differentiate it from gss? > > That certainly works for me, and makes sense to me. Ok, I actually have this working now, pending a few cleanups. Do you have a dev box with 8.3 on it that you could run some tests on? I could send over a libpq.dll compiled to support both GSSAPI and SSPI (and krb5) and you could verify it in your env? //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> Ok, I actually have this working now, pending a few cleanups.
Awesome!
> Do you have a dev box with 8.3 on it that you could run some tests on? I
> could send over a libpq.dll compiled to support both GSSAPI and SSPI (and
> krb5) and you could verify it in your env?
Sure, I can get that set up, feel free to email it to me.
Thanks!
Stephen