Re: SASL, compression? - Mailing list pgsql-hackers

From Bear Giles
Subject Re: SASL, compression?
Date
Msg-id 200205200711.BAA11326@eris.coyotesong.com
Whole thread Raw
In response to Re: SASL, compression?  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Responses Re: SASL, compression?
List pgsql-hackers
> What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL?
SASL is orthogonal to SSL.  SASL is an application-layer library
and can be run over either regular sockets or SSL.  However there
are SASL hooks to tell it that it's running over a secure channel.

The anticipated benefit of SASL is that it would replace all of the
current authetication code with a set of standard plugins.  The 
authority problem would be reduced to a simple text mapping.

(BTW, I didn't make it clear earlier but "authentication" is figuring
out who the other party is, "authority" is figuring out what they're
entitled to do.)

PAM is *not* a solution to network authentication since it was never
designed for it.  One well-known nightmare scenario is the Kerberos
PAM modules - they were designed to be used by local users logging
onto a virtual terminal, to eliminate the need to modify login to
acquire Kerberos credentials directly.  But in the wild they've been 
seen used with Apache "mod_pam" modules to "autheticate" Kerberos
users.  Since they require the Kerberos principal and password to be 
transmitted across the wire in the clear, they're major security holes
when used this way.

> Coz Postgresql already supports SSL right?

Postgresql minimally supports SSL.  It contains some significant
coding errors, poor initialization, and no support for client
certificates.  My recent patches should go a long way towards 
fixing that.

Bear


pgsql-hackers by date:

Previous
From: Bear Giles
Date:
Subject: revised SSL patches submitted
Next
From: Tatsuo Ishii
Date:
Subject: Re: [BUGS] Bug #659: lower()/upper() bug on