> 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.

Here's a patch that fixes the big problem and reverts the behaviour of
appl_version to be compatible with 8.0. It's easy enough to isolate the
changes that are around the appl_version - one line in
backend/libpq/auth.c call to krb5_recvauth and one in
interfaces/libpq/fe-auth.c call to krb5_sendauth.

The call in backend/libpq/auth.c to krb5_sname_to_principal in 8.1beta2
was completely broken for a scenario where you *didn't* use virtual
hosts, by setting pg_krb5_server to NULL... The call is needed there as


Attachment: krb5fix.patch
Description: krb5fix.patch

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to