> > 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.
>
> How important is that really? How many win32 users are
> likely to be using Kerberos auth with 8.0?
Not all that many - especially since it required a recompile to work
with AD. But some, I know of at least a couple who have mailed me about
instructions on how to do it, for example.
I don't know how many other cases changed principal names are used in,
though - we had the functionality to change it in the backend long
before we supported kerberos on windows.
> > 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.
>
> I don't really buy that argument. ISTM we should fix the
> code to do the right thing, especially if the right thing is
> more secure. If I understood what you said properly,
> hardwiring it as "postgres" is the correct thing, and loss of
> compatibility in marginal cases is just the price we pay for
> having done it wrong originally.
I said it was probably cleaner, which may or may not be the same as
"correct". It's very hard to find good documentation about the
krb5_sendauth/recvauth calls, so I'm not very sure about that - that's
why I'm asking before coding. The best I've found now that I searched
some more states:
"The paramter appl_version is a string describing the application
protocol version which the client is expecting to use for this exchange.
If the server is using a different application protocol, an error will
be returned."
But we already deal with protocol versions outside of this, so there's
not need ot use that functionality. Then again, there is nothing in the
spec that prevents us from using it the way we have previously done
either.
Quick code-check shows that if we set it to NULL instead it disables the
check on MIT Kerberos for to fix exactly this kind of issue, but it
looks like it would cause a crash on Heimdal, so that's not realliy a
good idea either.
The point is I'm having a hard time seeing what the actual gain is in
not changing it back. If the principal name mismatches, we're going to
get rejected anyway, so it's not really a problem there. Even though the
gain in changing it back isn't all that big either, why should we
introduce abackwards-incompatibility if there is no real gain in a
different part of the code.
//Magnus
