Kerberos brokenness and oops question in 8.1beta2

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Kerberos brokenness and oops question in 8.1beta2
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE92E70D@algol.sollentuna.se
обсуждение исходный текст
Ответы Re: Kerberos brokenness and oops question in 8.1beta2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi!

First of all, Kerberos v5 is quite broken in 8.1 beta2. The patch to
allow virtual hosts to be specifed quite efficiently broke everything
case that wasn't using it. I'm working on a patch for this, should be
ready by tomorrow.
(sorry didn't notice earlier, haven't started looking at putting my
kerberos-based systems on 8.1 until just now..)

This is clearly a must-fix.


The second point is an "oops" I introduced in my own kerberos patch
earlier on in 8.1, that I stumbled upon now.

Summary: When talking kerberos in particular you have a service
principal name, which is made out of hostname, service name and realm.
Service name is what's interesting here. It was previously set using
--with-krb-srvnam, and in 8.1 we can set it with a config option in
postgresql.conf.
PostgreSQl uses the calls to krb5_sendauth/krb5_recvauth to
authenticate. These calls take another parameter (that's not strictly in
the kerberos protocol, IIRC, just in the API) called "application name".
If this mismatches, authentication will fail.

Now, in <= 8.0, this application name was set to the same as the service
name (default "postgres", but in an active directory deployment for
example, it would be "POSTGRES"). This is not correct (the app name
doesn't change..), but that's how it has been.

In 8.1, this was changed to be hardcoded to "postgres". In part this was
done to prevent a very very simple way to cause a security issue in the
MIT kerberos libs. This issue has been fixed now, but I forgot all about
it. The other reason is that it's more up to api specs now.

Anyway. This makes it impossible for a 8.1 client to connect to a 8.0
server, or a 8.0 client to a 8.1 server, in any case where the service
name has changed - such as a win32 active directory deployment, but I'm
sure many others as well.

The only real advantage to how it is now is that it's "cleaner". The
argument that it protects against a security hole in MIT KRB5 doesn't
hold any more because there is a patch out, and we can't take
responsibility for people who haven't patched.

So, the bottom line is that I'd like to reverse this part of the patch
out, and go back to using the service name as the application name. I
don't think it's worth to lose the backwards compatibility just to make
it "a tiny bit cleaner".

Comments on this? I'd like to include this in the other kerberos fix I'm
working on, and have this in before beta3 if approved.

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Oracle buys Innobase
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Kerberos brokenness and oops question in 8.1beta2