Re: SASL, compression?

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

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

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

> 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