I've been looking at the authentication and networking code and
would like to float a trial balloon.
1) add SASL. This is a new standards-track protocol that is often
described as "PAM" for network authentication. PostgreSQL could
remove *all* protocol-specific authentication code and use
standard plug-in libraries instead.
(It's worth noting that SSL/TLS operates at a lower level than
SASL. This has some interesting consequences, see below.)
After the black-box authentication finishes, the postmaster will
have up to pieces of information: the peer's client cert (SSL)
and a string containing the Kerberos principal, user name verified
with password/one-time-password/CRAM, etc.
PostgreSQL authentication would be reduced to specifying which
authentication methods are acceptable for each database, then
mapping that authenticated user string and/or cert to a pguser.
2) add ZLIB compression.
The last point needs a bit of explanation. With SASL, the buffers
may be modified due to the authentication protocol selected, so the
low-level routines in pqcomm.c and fe-connect.c must be modified.
But since this is happening anyway, it would be easy to wrap
sasl_encode with ZLIB compression and sasl_decode with ZLIB decompression,
with pq_flush() (and client's equivalent) doing a "sync flush" of
the compression buffer.
You obviously don't need compression on the Unix socket or a fast
network connection, but if you're on a T1 or slower the reduced
transmission time should more than offset the time spent in
compression/decompression.
Drawbacks
The biggest drawback, at least initially, is that the initial
exchange will need to be totally rewritten. One possibility
could use something like this:
S: 220 example.com PostgreSQL 8.1
C: HELO client.com
S: 250-example.com
S: 250-AUTH ANONYMOUS KERBEROS4 <list of authentication methods>
S: 250-STARTTLS <server accepts SSL/TLS>
S: 250-COMPRESSION <compress datastream>
S: 250 HELP
C: STARTTLS pq.virtual.com <allows virtual domains>
<SSL/TLS negotation occurs *here*>
S: 250-pq.virtual.com
S: 250-AUTH ANONYMOUS PLAIN KERBEROS4 <note extra method>
S: 250-COMPRESSION
S: 250-some extract functions only available with TLS/SSL sessions
S: 250 HELP
C: AUTH PLAIN user password <use simple username/password>
S: 220 OK
C: COMPRESSION ON
S: 220 OK
C: OPEN database
S: 220 OK
and then the system drops back to the existing data exchange
format. Or it could look like something entirely different - the
most important thing is that the server needs to provide a list
of authentication methods, the client chooses one, and it either
succeeds or the client can retry. However a protocol something
like this has the strong advantage of being well-tested in the
existing protocols.
Bear
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
