Re: [HACKERS] Future of krb5 authentication
On Wed, Jul 18, 2007 at 06:01:33PM -0400, Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
On Thu, Jul 19, 2007 at 06:38:08AM -0400, Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
[HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Future of krb5 authentication
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
[EMAIL PROTECTED] (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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Future of krb5 authentication
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
Tom Lane [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Future of krb5 authentication
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
* Tom Lane ([EMAIL PROTECTED]) wrote: Magnus Hagander [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Dave Page ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Joshua D. Drake ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) 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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) 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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Future of krb5 authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Future of krb5 authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of krb5 authentication
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
* Heikki Linnakangas ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
Heikki Linnakangas [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Future of krb5 authentication
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Future of krb5 authentication
* Gregory Stark ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Future of krb5 authentication
* Tom Lane ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
