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
|
Список | 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 по дате отправления: