Thread: Re: [HACKERS] Kerberos brokenness and oops question in 8.1beta2
> 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 well. //Magnus
Attachment
"Magnus Hagander" <mha@sollentuna.net> writes:
> Here's a patch that fixes the big problem and reverts the behaviour of
> appl_version to be compatible with 8.0.
Applied with trivial stylistic cleanups.
BTW, the documentation seems a bit broken:
krb_server_hostname (string)
Sets the hostname part of the service principal. This, combined
with krb_srvname, is used to generate the complete service
principal, i.e. krb_server_hostname/krb_server_hostname@REALM.
I suppose one of those last two should be "krb_srvname", but which?
regards, tom lane
I need a comment on this. --------------------------------------------------------------------------- Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > > Here's a patch that fixes the big problem and reverts the behaviour of > > appl_version to be compatible with 8.0. > > Applied with trivial stylistic cleanups. > > BTW, the documentation seems a bit broken: > > krb_server_hostname (string) > > Sets the hostname part of the service principal. This, combined > with krb_srvname, is used to generate the complete service > principal, i.e. krb_server_hostname/krb_server_hostname@REALM. > > I suppose one of those last two should be "krb_srvname", but which? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
This has been fixed in current CVS: <varname>krb_srvname</><literal>/</><varname>krb_server_hostname</><literal>@</>REALM. --------------------------------------------------------------------------- Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > > Here's a patch that fixes the big problem and reverts the behaviour of > > appl_version to be compatible with 8.0. > > Applied with trivial stylistic cleanups. > > BTW, the documentation seems a bit broken: > > krb_server_hostname (string) > > Sets the hostname part of the service principal. This, combined > with krb_srvname, is used to generate the complete service > principal, i.e. krb_server_hostname/krb_server_hostname@REALM. > > I suppose one of those last two should be "krb_srvname", but which? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073