Skip site navigation (1) Skip section navigation (2)

Re: JAVA Support

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: JAVA Support
Date: 2006-09-29 15:50:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sep 28, 2006, at 9:35 PM, Tom Lane wrote:

> "Joshua D. Drake" <jd(at)commandprompt(dot)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(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-29 15:57:39
Subject: Re: Block B-Tree concept
Previous:From: Tom LaneDate: 2006-09-29 15:40:32
Subject: Re: Another idea for dealing with cmin/cmax

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group