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@sss.pgh.pa.us> writes:
> 
> > Daniel Ahlin <dah@pdc.kth.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@postgresql.org
> 

--  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,
Pennsylvania19073