SASL, compression? 
Author Message
 SASL, compression?


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

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.***.com/



Fri, 05 Nov 2004 19:57:01 GMT
 SASL, compression?

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

Remember that the current authentication code requires that each
database specify the method(s) used to access it.  With SASL, it
should be possible to specify generic sensitivities (e.g., 'public,'
'low,' 'high' and 'extreme') and let the systems negotiate any
authentication method that satisfies the properties indicated by
these sensitivities.  Including local authentication methods that
we've never heard of.

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

Some clients can allow the user to specify a mechanism, but others
will require the client to autonegotiate the authentication.  Exactly
how we'll handle this is one of the open questions.

Quote:
> 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?

The authorization question HBA deals with is mapping Kerberos principals
to pgusers.  That level of authorization is handled by the database,
not postmaster.

Quote:
> 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?

A lot of CAs won't sign certs with wildcards.  They aren't
necessary since you can set up the nameserver to provide aliasing.
It's also possible to add an arbitrary number of altSubjName extensions,
so you could always explicitly name all systems if you wanted.

Adding reverse DNS lookup and support for altSubjName extensions
is on my todo list, but was a lower priority than getting the big
patch out for feedback.

As for loosening the cert verification checks, I think a better
solution is providing a tool that makes it easy to create good certs.
It's too easy to come up with man-in-the-middle attacks if it's easy
to disable these checks.

As a compromise, I think it may be possible to run the server with
*no* cert.  This option would be used by sites that only want an
encrypted channel, and sites that want authentication will make the
commitment to creating valid certs.

Bear

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Fri, 05 Nov 2004 23:29:45 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Using LDAP SASL to connect to OID

2. 3 rb bit. - New method for media reconstruction / compression (3 bit compression)

3. 3 rb bit. - New method for media reconstruction / compression (3 bit compression)

4. NTFS Compression Corruption

5. Compression

6. Small compression function in C/C++ needed.

7. data compression techniques

8. Data Compression with A Cursor

9. Transaction Log Compression.

10. Data compression

11. SubmitSQL and compression


 
Powered by phpBB® Forum Software