Re: SASL, compression?

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.