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

At 01:11 AM 5/20/02 -0600, Bear Giles wrote:
> > What are the benefits of SASL+Postgresql compared to Postgresql over 
> plain SSL?
>
>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.

[I'm not a pgsql hacker, so feel free to ignore me :) ]

I can see the benefit of SASL as a standard in public exposed network 
services like email servers (SMTP, POP, IMAP), where you can support 
different email clients which themselves may or may not support SASL and 
may use different SASL libraries.

But for Postgresql - communications is mainly between internal db clients 
(which use the pgsql libraries) and postmaster.

Would the SASL code allow JDBC, Perl DBI+DBD postgresql clients support 
SASL (and encryption) seamlessly? If it would then that's great. If it's 
just psql then not so great.

Because replacing current authentication code doesn't seem as obvious a 
benefit to me. The plugin thing sounds useful tho - modular. But would the 
simple text mapping for authorisation be as simple when UserX is only 
supposed to have SELECT access to certain tables?

To me there may be more bang for the buck by improving support for network 
layer tunnels- like SSL (SASL has more application layer stuff). Maybe even 
support plugins for network layer tunnels, rather than plugins for 
authentication.  Because Postgresql already provides authentication and 
authorisation, we may just need compression/encryption/other tunneling in 
various forms.

Would something like this be possible:
For postgresql clients - standardise on two handles for input and output 
(ala djb's tcpserver), set environment variables, exec/fork a tunnelapp 
with argument string. The tunnelapp will read from output handle, write to 
input handle, and make connection to the tunnelserver (which is where 
things get difficult - postmaster)..

Then you could have an SASL tunnelapp, an SSL tunnelapp, an SSH tunnelapp.

This would be bad for O/Ses with not so good forks support like solaris and 
windows. But the point is - isn't there some other way to abstract the 
network/IO layer stuff so that even recompiles aren't necessary?

So if there's a bug in the tunnel app it's not a Postgresql problem - only 
the tunnel app needs to be fixed.

> > 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.

Cool. WRT the patch which requires strict matches on server hostnames - are 
wildcards allowed or is there an option for the client to ignore/loosen 
things a bit?

Cheerio,
Link.