Re: JAVA Support

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-30 03:12:47
Message-ID: 200609300312.k8U3ClE08649@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-09-30 03:55:18 Re: Per-database search_path
Previous Message Joshua D. Drake 2006-09-30 02:31:21 Re: Win32 hard crash problem