Thread: JAVA Support
It appears that the JDBC client doesn't include the Kerberos support that the C clients do. So, two questions: 1) Is there an alternative JDBC client that's just a glue layer instead of a complete re-implementation? 2) If I were willing to add a GSSAPI or SASL layer as an alternative to the bare Krb 5 support would anyone be willing to help with the supporting mods to the pg_hba.conf parsing, and configure? ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Thu, 28 Sep 2006, Henry B. Hotz wrote: > It appears that the JDBC client doesn't include the Kerberos support > that the C clients do. Java doesn't have accessible Kerberos support. It wraps Kerberos in GSSAPI which requires the server to support GSSAPI instead of plain Kerberos. > So, two questions: > > 1) Is there an alternative JDBC client that's just a glue layer instead of a > complete re-implementation? No, there aren't any Type 2 drivers around. Requiring native code is a giant pain. Kris Jurka
On Sep 28, 2006, at 10:52 AM, Kris Jurka wrote: > > > On Thu, 28 Sep 2006, Henry B. Hotz wrote: > >> It appears that the JDBC client doesn't include the Kerberos >> support that the C clients do. > > Java doesn't have accessible Kerberos support. It wraps Kerberos > in GSSAPI which requires the server to support GSSAPI instead of > plain Kerberos. Looks like Kerberos is the only GSSAPI mechanism supported in Java. OK by me, but that's not the point of the standard (or the SASL standard). >> So, two questions: >> >> 1) Is there an alternative JDBC client that's just a glue layer >> instead of a complete re-implementation? > > No, there aren't any Type 2 drivers around. Requiring native code > is a giant pain. > > Kris Jurka Requiring JAVA support for everything you can do with C is also a pain, isn't it? (This incompatibility being an example.) I take it you're not volunteering to help with my second request. ;-) ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Thu, 28 Sep 2006, Henry B. Hotz wrote: > I take it you're not volunteering to help with my second request. ;-) > I would if we could get some -hackers buy in on the idea. Adding more and more auth methods is something they're not excited about unless there's a good reason (which I think this is). Kris Jurka
> 2) If I were willing to add a GSSAPI or SASL layer as an > alternative to the bare Krb 5 support would anyone be willing > to help with the supporting mods to the pg_hba.conf parsing, > and configure? Sure, I can help out with that. I've done a bunch of work on the current kerberos stuff (tohugh I'm by no means the author) in order to make it work on win32, so I have a little bit of a clue around that code ATM. As for the other part - will core accept this - I can't answer that. I do beleive that there is a point to it, given that Java will then support it natively, but I'm not core. I'm unsure if there is a clear view on the merits of adding more authentication options.. //Magnus
On Sep 28, 2006, at 12:42 PM, Magnus Hagander wrote: >> 2) If I were willing to add a GSSAPI or SASL layer as an >> alternative to the bare Krb 5 support would anyone be willing >> to help with the supporting mods to the pg_hba.conf parsing, >> and configure? > > Sure, I can help out with that. I've done a bunch of work on the > current > kerberos stuff (tohugh I'm by no means the author) in order to make it > work on win32, so I have a little bit of a clue around that code ATM. > > As for the other part - will core accept this - I can't answer that. I > do beleive that there is a point to it, given that Java will then > support it natively, but I'm not core. I'm unsure if there is a clear > view on the merits of adding more authentication options.. From the lack of traffic on this list I gather that the core developers no longer hang out here. I've been gone for a few years. For the record here's the arguments: SASL is a "standards track RFC" (I saw those snide comments in the record, Mr. Lane ;-) which allows you to plug in authentication mechanisms, much like PAM allows you to plug in password checkers. It is well adopted, since it forms the basis of most email protocols' authentication, as well as LDAP and Jabber. SASL provides a unified way for code to support all the authentication options you're likely to want. a) In the absence of OS-provided SASL libraries a simple password- checking mechanism could be implemented as a wire-compatible fallback with less code than the framework would take. (I won't write this, but you could probably steal code from jabberd.) b) SASL includes simple password checking mechanisms. In principle we could use these to check the local postgres passwords. Not sure how much customization that would require. c) If you are using SSL/TLS for client/server connections (or it's a local on-machine connection) you can use the SASL_EXTERNAL mechanism to pick up the identity from the connection, without imposing extra overhead. d) SASL includes enterprise-class authentication support, such as GSSAPI (and Kerberos via GSSAPI). If an enterprise has some unique authentication infrastructure it can be implemented as a SASL (or GSSAPI) plug-in without the need to customize PostgreSQL. e) After the initial connection, SASL can be configured to run the connection fully encrypted, integrity protected, or unprotected. f) SASL support is available in current Java as well as C. SASL libraries are included (or at least loadable) on MacOS, Solaris 10+, and Linux. (I don't do windows, so I can't say there.) While it has a reputation for complexity, that complexity is in building the libraries, not in using them. It can be used to provide most (all?) of the functionality now provided by the assortment of existing mechanisms. If provided as an alternative, it could eventually allow decommissioning of a lot of the other mechanisms. If the number of existing mechanisms is an issue, then this could be a big long-term win. I'll assume the ball is in my court now, unless someone wants to claim I should just do GSSAPI and not bother with the higher level. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> > As for the other part - will core accept this - I can't > answer that. I > > do beleive that there is a point to it, given that Java will then > > support it natively, but I'm not core. I'm unsure if there > is a clear > > view on the merits of adding more authentication options.. > > From the lack of traffic on this list I gather that the core > developers no longer hang out here. I've been gone for a few years. Oh, they most definitly do. Every one of them. They just don't write in every single thread (though sometimes I wonder about Tom..) I noticed you copied Tom Lockhart - he isn't core anymore, so don't expect a response there. Tom Lane is, though, and I'm sure he'll respond. > For the record here's the arguments: <snip a bunch of SASL arguments that I'm sure are perfectly valid> > f) SASL support is available in current Java as well as C. > SASL libraries are included (or at least loadable) on MacOS, > Solaris 10+, and Linux. (I don't do windows, so I can't say > there.) While it has a reputation for complexity, that > complexity is in building the libraries, not in using them. > > It can be used to provide most (all?) of the functionality > now provided by the assortment of existing mechanisms. Well, it's still a complexity you need to deal with. Plus, just Java and C is far from enough, if you are intending to suggest we replace some of what we have now with it (like passwords and other such things). For example, you need things like perl, python, ruby, C#, etc etc. not sure how many of those would be fine with a C wrapper, I know for a fact that C# (or other .net languages) wouldn't, they need it natively. There also used to be some bad portability issues wrt at least some of the SASL libraries (if there is more than one). I know I tried to make it work on win32 once and failed miserably. (Then again, I've failed on Linux as well, but not quite as bad. And it's not included in all Linux distributions, at least it wasn't when I checked a while back) And finally, there's backwards compatibility. We're still going to have to support all the existing ones for the forseeable future unless you want to prevent all older clients from connecting (hint: you don't). > If provided as an alternative, it could eventually allow > decommissioning of a lot of the other mechanisms. If the > number of existing mechanisms is an issue, then this could be > a big long-term win. Me, I think providing it as an alternative is the path to go. Which also means that I think implementing GSSAPI for that (probably in long-term to *replace* our current Kerberos authentication, in short-term to complement it) rather than SASL, because it's significantly simpler. > I'll assume the ball is in my court now, unless someone wants > to claim I should just do GSSAPI and not bother with the higher level. That would be my suggestion - do GSSAPI only and leave the current methods the way they are. This should be doable without a huge amount of code, and without affecting the other well-working mechanisms. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
> As for the other part - will core accept this - I can't answer that.
It would depend in part on the size of the patch, and on whether there
are any arguments for supporting GSSAPI besides "Java can't do Kerberos".
What would it buy for a libpq user?
regards, tom lane
> > As for the other part - will core accept this - I can't answer that. > > It would depend in part on the size of the patch, and on > whether there are any arguments for supporting GSSAPI besides > "Java can't do Kerberos". > What would it buy for a libpq user? I don't know, really ;-) It seems we're fairly alone in *not* doing GSSAPI (given for example the MIT Kerberos bug I uncovered when working on it, that was at the very core of the codepath we're using, which shows that others arne't using that). We'd be using a much better tested code, I think. It *may* be that life on win32 would be much easier, given that Windows SSPI is supposed to be compatible with GSSAPI when used in the right way. I don't know any details about this, though. If it does, it would likely make life easier for .NET applications as well, not just Java. I'll leave it to Henry to add some more arguments :-) //Magnus
Kris, > I would if we could get some -hackers buy in on the idea. Adding > more and more auth methods is something they're not excited about > unless there's a good reason (which I think this is). Actually, I've been trying to get some of the Sun engineers to contribute patches for Solaris authentication methods, of which GSSAPI is one. So in theory someone from Sun should be looking at coding this. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500
Tom, > It would depend in part on the size of the patch, and on whether > there > are any arguments for supporting GSSAPI besides "Java can't do > Kerberos". > What would it buy for a libpq user? According to the Solaris Security engineers, GSSAPI is more secure than using the Kerberos headers. Also, in theory GSSAPI is supposed to support multiple authentication back-ends (ldap, liberty, etc.), but I personally have never seen support for anything but Kerberos. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500
On Sep 28, 2006, at 2:24 PM, Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: >> As for the other part - will core accept this - I can't answer that. > > It would depend in part on the size of the patch, and on whether there > are any arguments for supporting GSSAPI besides "Java can't do > Kerberos". > What would it buy for a libpq user? Everything that the current Kerberos support provides plus Java. Ability to encrypt or integrity protect the client/server connection (without SSL/TLS tunnels). In theory, you get to plug in other mechanisms than Kerberos. In practice I think this only worked on Solaris, until very recently. The free gssapi implementations in Java, Solaris, MIT Kerberos, and Heimdal Kerberos only supported Kerberos. Sun open sourced their mechanism glue code and it's being incorporated into both MIT (now) and Heimdal (0.8). Entrust sells a PKI mechanism for Solaris. Wire compatibility with a native Windows API (the SSPI), if it's used correctly. (Google for posts by Jeffrey Altman for references to example code.) ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
I cc'ed Tom Lockhart because he *used* to be core, and I know where he works. No response expected. On Sep 28, 2006, at 2:11 PM, Magnus Hagander wrote: >> f) SASL support is available in current Java as well as C. >> SASL libraries are included (or at least loadable) on MacOS, >> Solaris 10+, and Linux. (I don't do windows, so I can't say >> there.) While it has a reputation for complexity, that >> complexity is in building the libraries, not in using them. >> >> It can be used to provide most (all?) of the functionality >> now provided by the assortment of existing mechanisms. > > Well, it's still a complexity you need to deal with. Plus, just > Java and > C is far from enough, if you are intending to suggest we replace > some of > what we have now with it (like passwords and other such things). For > example, you need things like perl, python, ruby, C#, etc etc. not > sure > how many of those would be fine with a C wrapper, I know for a fact > that > C# (or other .net languages) wouldn't, they need it natively. OK, point taken. OTOH how many of those have GSSAPI support? I don't know, but I'd guess that only going as far as GSSAPI gets you C# (and .net), and Java of course. Perl probably isn't a big deal just using glue for either SASL or GSSAPI. Python and Ruby I don't know. > There also used to be some bad portability issues wrt at least some of > the SASL libraries (if there is more than one). There's more than one, since the Java one is different from Cyrus. I've seen references to others, but I think they qualify as "obscure". The Sun one is related to Cyrus. > I know I tried to make > it work on win32 once and failed miserably. (Then again, I've > failed on > Linux as well, but not quite as bad. And it's not included in all > Linux > distributions, at least it wasn't when I checked a while back) Well, I know Redhat has RPM's that look reasonable. I'm not a big Linux user myself. (More a BSD bigot, to be honest.) > And finally, there's backwards compatibility. We're still going to > have > to support all the existing ones for the forseeable future unless you > want to prevent all older clients from connecting (hint: you don't). No question. Just a thought for the future. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Sep 28, 2006, at 3:01 PM, Josh Berkus wrote: > Kris, > >> I would if we could get some -hackers buy in on the idea. Adding >> more and more auth methods is something they're not excited about >> unless there's a good reason (which I think this is). > > Actually, I've been trying to get some of the Sun engineers to > contribute patches for Solaris authentication methods, of which GSSAPI > is one. So in theory someone from Sun should be looking at coding > this. Sun demonstrated that you could build the existing Kerberos support with the current Solaris 11 beta's. They opened the "native" MIT Kerberos API for outside use. See posts on the [ports] list. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Sep 28, 2006, at 3:03 PM, Josh Berkus wrote: > Tom, > >> It would depend in part on the size of the patch, and on whether >> there >> are any arguments for supporting GSSAPI besides "Java can't do >> Kerberos". >> What would it buy for a libpq user? > > According to the Solaris Security engineers, GSSAPI is more secure > than > using the Kerberos headers. Also, in theory GSSAPI is supposed to > support multiple authentication back-ends (ldap, liberty, etc.), but I > personally have never seen support for anything but Kerberos. I think that GSSAPI is more tolerant of connections through NAT's. I think it's more robust to current network reality, but I'm not aware it's actually more secure if you're using comparable verification options. As noted elsewhere on this thread it's more available. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Henry, > Sun demonstrated that you could build the existing Kerberos support > with the current Solaris 11 beta's. They opened the "native" MIT > Kerberos API for outside use. Yes, and this will be available via the supported version in Solaris 10 Update 4. However, that doesn't change that some people would like us to support GSSAPI, and there may be some benefit (additional applications, better network authentication, etc.) for doing so. If we can get additional programmers to code the support (i.e. Sun, JPL) I don't see any reason not to support the *additional* authentication methods. -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> However, that doesn't change that some people would like us to support
> GSSAPI, and there may be some benefit (additional applications, better
> network authentication, etc.) for doing so. If we can get additional
> programmers to code the support (i.e. Sun, JPL) I don't see any reason
> not to support the *additional* authentication methods.
Well, as I said already, a lot depends on the size of the patch.
As a reductio ad absurdum, if they drop 100K lines of code on us,
it *will* get rejected, no matter how cool it is.
The current Kerberos support seems to require about 50 lines in
configure.in and circa 200 lines of C code in each of the backend
and libpq. Plus a dependency on an outside library that happens
to be readily available and compatibly licensed.
What amount of code are we talking about adding here, and what
dependencies exactly? What portability and license hazards will
be added?
regards, tom lane
Josh Berkus wrote: > Henry, > >> Sun demonstrated that you could build the existing Kerberos support >> with the current Solaris 11 beta's. They opened the "native" MIT >> Kerberos API for outside use. > > Yes, and this will be available via the supported version in Solaris 10 Update > 4. > > However, that doesn't change that some people would like us to support GSSAPI, > and there may be some benefit (additional applications, better network > authentication, etc.) for doing so. If we can get additional programmers to > code the support (i.e. Sun, JPL) I don't see any reason not to support the > *additional* authentication methods. Is there any reason why we haven't built a generic authentication API? Something like PAM, except cross platform? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Is there any reason why we haven't built a generic authentication API?
> Something like PAM, except cross platform?
We're database geeks, not security/crypto/authentication geeks. What
makes you think we have any particular competence to do the above?
Actually, the part of this proposal that raised my hackles the most was
the claim that GSSAPI provides a generic auth API, because that was
exactly the bill of goods we were sold in connection with PAM. (So why
is this our problem at all --- can't you make a PAM plugin for it??)
It didn't help any that that was shortly followed by the lame admission
that no one has ever implemented anything except Kerberos underneath it.
Word to the wise, guys: go *real* soft on vaporware claims for auth
stuff, because we've seen enough of those before.
regards, tom lane
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Is there any reason why we haven't built a generic authentication API? >> Something like PAM, except cross platform? > > We're database geeks, not security/crypto/authentication geeks. What > makes you think we have any particular competence to do the above? Well that is a valid point :). I was just asking. Joshua D. Drake > > Actually, the part of this proposal that raised my hackles the most was > the claim that GSSAPI provides a generic auth API, because that was > exactly the bill of goods we were sold in connection with PAM. (So why > is this our problem at all --- can't you make a PAM plugin for it??) > It didn't help any that that was shortly followed by the lame admission > that no one has ever implemented anything except Kerberos underneath it. > Word to the wise, guys: go *real* soft on vaporware claims for auth > stuff, because we've seen enough of those before. > > regards, tom lane > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> > I would if we could get some -hackers buy in on the idea. Adding > more > > and more auth methods is something they're not excited about > unless > > there's a good reason (which I think this is). > > Actually, I've been trying to get some of the Sun engineers to > contribute patches for Solaris authentication methods, of which > GSSAPI is one. So in theory someone from Sun should be looking at > coding this. Well, if they are, I hope they would be speaking up now, so work isn't duplicated... So if you're out there, please speak up! ;-) //Magnus
> > However, that doesn't change that some people would like us to > support > > GSSAPI, and there may be some benefit (additional applications, > better > > network authentication, etc.) for doing so. If we can get > additional > > programmers to code the support (i.e. Sun, JPL) I don't see any > reason > > not to support the *additional* authentication methods. > > Well, as I said already, a lot depends on the size of the patch. > As a reductio ad absurdum, if they drop 100K lines of code on us, > it *will* get rejected, no matter how cool it is. Oh, absolutely. > The current Kerberos support seems to require about 50 lines in > configure.in and circa 200 lines of C code in each of the backend > and libpq. Plus a dependency on an outside library that happens to > be readily available and compatibly licensed. I would expect, without looking at the details of the API, GSSAPI to be about the same amount of code if not less. > What amount of code are we talking about adding here, and what > dependencies exactly? What portability and license hazards will be > added? The Kerberos5 libraries that we rely on today provide GSSAPI. So it would work with the same external library. Now, it could *also* work with other libraries in some cases (for example, the Win32 SSPI libraries), but with the same libraries it should work fine. //Magnus
This being SASL: > > I know I tried to make > > it work on win32 once and failed miserably. (Then again, I've > failed > > on Linux as well, but not quite as bad. And it's not included in > all > > Linux distributions, at least it wasn't when I checked a while > back) > > Well, I know Redhat has RPM's that look reasonable. I'm not a big > Linux user myself. (More a BSD bigot, to be honest.) Well, Redhat != Linux, really :P Over to GSSAPI: > In theory, you get to plug in other mechanisms than Kerberos. In > practice I think this only worked on Solaris, until very recently. FWIW, Microsoft have supported NTLM over GSSAPI since.. eh. Back in 1999, I guess, with the first pre-releases of Windows 2000. > Wire compatibility with a native Windows API (the SSPI), if it's > used correctly. (Google for posts by Jeffrey Altman for references > to example code.) This, IMHO, is a big win if we can pull it off. It would significantly lower the barrier for getting Kerberos working properly in pg on Win32. //Magnus
On Sep 28, 2006, at 9:35 PM, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Is there any reason why we haven't built a generic authentication >> API? >> Something like PAM, except cross platform? > > We're database geeks, not security/crypto/authentication geeks. What > makes you think we have any particular competence to do the above? > > Actually, the part of this proposal that raised my hackles the most > was > the claim that GSSAPI provides a generic auth API, because that was > exactly the bill of goods we were sold in connection with PAM. (So > why > is this our problem at all --- can't you make a PAM plugin for it??) > It didn't help any that that was shortly followed by the lame > admission > that no one has ever implemented anything except Kerberos > underneath it. > Word to the wise, guys: go *real* soft on vaporware claims for auth > stuff, because we've seen enough of those before. Well, that's why I was pushing SASL instead of GSSAPI. There are multiple mechanisms that are actually in use. PAM turned out not to be sufficiently specified for cross-platform behavioral compatibility, and it only does password checking anyway. Calling it a security solution is a big overstatement IMO. I guess a lot of people use PAM with SSL and don't worry about the gap between the two (which SASL or GSSAPI close). In defense of GSSAPI non-Kerberos mechanisms do exist. They just cost money and they aren't very cross-platform. AFAIK GSSAPI has no simple password mechanisms. There's a Microsoft-compatible SPNEGO mechanism for GSSAPI that's being implemented fairly widely now, but it's just a sub-negotiation mech that lets you choose between a Kerberos 5 (that's practically identical to the direct one), and NTLM. If you allow NTLM you'd better limit it to NTLMv2! ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote: >>> However, that doesn't change that some people would like us to >> support >>> GSSAPI, and there may be some benefit (additional applications, >> better >>> network authentication, etc.) for doing so. If we can get >> additional >>> programmers to code the support (i.e. Sun, JPL) I don't see any >> reason >>> not to support the *additional* authentication methods. >> >> Well, as I said already, a lot depends on the size of the patch. >> As a reductio ad absurdum, if they drop 100K lines of code on us, >> it *will* get rejected, no matter how cool it is. > > Oh, absolutely. > > >> The current Kerberos support seems to require about 50 lines in >> configure.in and circa 200 lines of C code in each of the backend >> and libpq. Plus a dependency on an outside library that happens to >> be readily available and compatibly licensed. > > I would expect, without looking at the details of the API, GSSAPI > to be > about the same amount of code if not less. Probably save some Kerberos bookkeeping. Probably loose it with GSSAPI bookkeeping, including name translation (which is far less obvious). Net, I would expect to lose, but not by very much. >> What amount of code are we talking about adding here, and what >> dependencies exactly? What portability and license hazards will be >> added? > > The Kerberos5 libraries that we rely on today provide GSSAPI. So it > would work with the same external library. Now, it could *also* work > with other libraries in some cases (for example, the Win32 SSPI > libraries), but with the same libraries it should work fine. > > //Magnus If I had a lot of time to spend on this I would write a SASL-like wrapper so it could be used on platforms with GSSAPI, but not SASL support in the OS. As you may have noticed, I believe SASL is the way to go. I'm not up for it though. There's probably room in the world for a "SASL-lite" library though. Cyrus is great, but if your OS doesn't supply it for you, it's supposed to be really hard to build. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Henry B. Hotz wrote: > Well, that's why I was pushing SASL instead of GSSAPI. There are > multiple mechanisms that are actually in use. > > PAM turned out not to be sufficiently specified for cross-platform > behavioral compatibility, and it only does password checking anyway. > Calling it a security solution is a big overstatement IMO. I guess a > lot of people use PAM with SSL and don't worry about the gap between > the two (which SASL or GSSAPI close). > > In defense of GSSAPI non-Kerberos mechanisms do exist. They just > cost money and they aren't very cross-platform. AFAIK GSSAPI has no > simple password mechanisms. > > There's a Microsoft-compatible SPNEGO mechanism for GSSAPI that's > being implemented fairly widely now, but it's just a sub-negotiation > mech that lets you choose between a Kerberos 5 (that's practically > identical to the direct one), and NTLM. If you allow NTLM you'd > better limit it to NTLMv2! As already mentioned, the limitations of PAM weren't clear until after we implemented it, so I expect the same to happen here, and the number of acronyms flying around in this discussion is a bad sign too. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +