Re: iprop problem

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Nov 3, 2006, at 1:59 AM, Juha Jäykkä wrote:

>> As you say root can get what it wants.  It's just "wrong" to mix
>> unrelated things when you don't have to.  It makes sense to put the
>> "host" keys in the default keytab because they identify the machine
>> rather than a specific service.  A specific service should in general
>> have its own keytab file.  That way it *can* be run as something
>> other than root.
>
> You're definitely correct and I did not intend to imply otherwise.  
> This
> is a research lab (but not with the resources JPL has =) ),

You give us way too much credit.  Things are very fragmented here.

> which
> maintains its own kerberos realm with no personnel dedicated to
> administering it (or any other computer-related stuff either, for that
> matter). Thus we have very little time to make things as they  
> should be,
> so the guideline is to make everything "secure enough" with minimum
> amount of work. Changing keytabs means altering and maintaining the
> init-scripts of the service. During upgrades, those are easily  
> missed (or
> overwritten), causing more harm than what we *believe* can be  
> caused by
> keeping the keytabs together.
>
> Perhaps I'll try to take the time of separating the keytabs in the
> future (there is the upcoming upgrade from Debian sarge to etch; I  
> think
> we could make this at the same time). Which keys would you think  
> need to
> go to separate keytabs? Those services which run without root  
> privileges
> have, naturally, already their own keytabs. The question of imap,  
> ssh and
> nfs remains. These are all services that need root privileges, so we
> haven't bothered to separate them from each other. The keys for "host"
> will of course remain in the default keytab, but how about the others?

I've got no hard and fast rules, except don't put keytabs on network  
storage, like NFS.  I thought the FAQ had some advice, but I don't  
see anything that specific.

The environment variable KRB5_KTNAME seems to be a good, undocumented  
way to specify a process-unique keytab location without modifying or  
substituting krb5.conf.

>> Just something to try:  be explicit about all the file locations in
>> the kdc.conf file.  That helped when I had a similar problem.  I
>> think there is a bug in iprop that causes this, but I was never able
>> to fully trace it down.
>
> Thank you very much! That seemed to help. What's strange about it, is
> that it still uses *the exact same files* as before - except now it
> works, previously it didn't. Perhaps we'd better define this as a bug?

Want to send something in?  I'm not sure what I sent in addresses  
this issue properly because my examples were contaminated by other  
issues.

I can tell you that if you read the code it *looks* like it should do  
the right thing.

> Cheers!
>
> -Juha

------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu