Re: SASL, compression?
От | Bear Giles |
---|---|
Тема | Re: SASL, compression? |
Дата | |
Msg-id | 200205200711.BAA11326@eris.coyotesong.com обсуждение исходный текст |
Ответ на | Re: SASL, compression? (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Ответы |
Re: SASL, compression?
|
Список | pgsql-hackers |
> What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL? SASL is orthogonal to SSL. SASL is an application-layer library and can be run over either regular sockets or SSL. However there are SASL hooks to tell it that it's running over a secure channel. 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. (BTW, I didn't make it clear earlier but "authentication" is figuring out who the other party is, "authority" is figuring out what they're entitled to do.) PAM is *not* a solution to network authentication since it was never designed for it. One well-known nightmare scenario is the Kerberos PAM modules - they were designed to be used by local users logging onto a virtual terminal, to eliminate the need to modify login to acquire Kerberos credentials directly. But in the wild they've been seen used with Apache "mod_pam" modules to "autheticate" Kerberos users. Since they require the Kerberos principal and password to be transmitted across the wire in the clear, they're major security holes when used this way. > 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. Bear
В списке pgsql-hackers по дате отправления: