[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iprop problem
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.
> is a research lab (but not with the resources JPL has =) ),
You give us way too much credit. Things are very fragmented here.
> 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
> 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
> 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
>> 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
I can tell you that if you read the code it *looks* like it should do
the right thing.
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 email@example.com