Re: SASL, compression?
От | Bear Giles |
---|---|
Тема | Re: SASL, compression? |
Дата | |
Msg-id | 200205201522.JAA13493@eris.coyotesong.com обсуждение исходный текст |
Ответ на | Re: SASL, compression? (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: