Re: Allow change of kerberos service name without recompilation

No one has ever asked for a kerberos service name different from
"postgres". Unless someone else says this is a useful feature, I
think we are better off leaving our code unchanged.

Kerberos is pretty complicated so adding another configuration options
isn't always a good idea.

---------------------------------------------------------------------------

Daniel Ahlin wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Daniel Ahlin <dah(at)pdc(dot)kth(dot)se> writes:
> > > This is a two part patch against 7.4.5 implementing the option of
> > > configuring what is now set using the #defined constant PG_KRB_SRVNAM
> > > (the name of the service part of the kerberos principal the server
> > > uses).
> >
> > Is this a good idea? Offhand it just seems like another way for a
> > client to fail to establish communication with the server :-(.
>
> Certainly, in some sense it will give you more rope to hang
> yourself. However, please consider that as of now the service name is
> a compile time option, easily changable via configure option.
>
> That means that if you want a non-default setting of this, you have to
> use a backend and an interface compiled using the same or identical
> compilation settings. That, in turn, means that if you provide users
> with precompiled versions of the software, you have to provide them
> with one version for each servicename (which is of course just silly).
>
> What it boils down to is actually whether you think that differing
> servicenames should be allowed. That is, if you can see any valid use
> cases for it. I know there exist such, but it may only be in my
> particular setting.
>
> (From my perspective it is very much the same as providing a way to
> easily configure which port number to use. The situations where the
> need to change default behaviour is also probably similar.)
>
> > In any case, the patch is quite shy of documentation...
>
> I can provide more documentation if you feel that it is lacking (btw,
> do you mean usage- or code documentation or both).
>
> Then again, since the patchset is small and nonintrusive I have no
> vested intrest in getting the patch included (it will be easy enough
> to keep updated on site). I know I need it, you are welcome to use it
> if you want to.
>
> Either way, I would like to ask if the way the client handles the
> retrieval of the optional value (by explicit getenv in fe-auth.c) is
> the approved method or not. Perhaps something like what is found for
> PGHOST in fe-connect.c, would be better? If so, would it break the
> interfaces for the other languages using fe-connect?
>
> Regards
> Daniel Ahlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073