[3935] in Kerberos
Re: KRB5 problems
daemon@ATHENA.MIT.EDU (Ted Lemon)
Tue Sep 27 14:27:08 1994
To: ramus@nersc.gov (Joe Ramus)
Cc: jprondak@earth.ml.com, kerberos@MIT.EDU
In-Reply-To: Your message of "Tue, 27 Sep 1994 10:52:08 PDT."
<9409271752.AA27185@windsail.nersc.gov>
Date: Tue, 27 Sep 1994 11:06:42 -0700
From: Ted Lemon <mellon@ipd.wellsfargo.com>
> What are the symptoms of "kerberos library loses horribly" ??
My apologies - that is a rather imprecise description of the problem,
isn't it?
What I mean is that when the kerberos library calls fcntl or flock (I
can't remember which one it winds up using) to set a lock on the file,
it gets an EINVAL back. Since it must set a lock before it can do
anything to the ticket file, it bombs immediately.
I discovered this when trying to forward a ticket with telnet. It's
possible that if you use a different code path, you don't run into
this problem. However, the person who asked the original question
was having the same problem with kinit.
So I'm not sure why you're not having the problem. Maybe you're
running a previous version which doesn't check the status of the
locking system call in the same way. Or maybe I've incompletely
diagnosed what went wrong. All I know is that when I moved the
ticket cache from /tmp, the problem went away, and that the SunOS
documentation for 4.1.3U1 claims that tmpfs doesn't support locking.
As to the security issues of putting the file in /tmp, I don't see how
this is a problem. If you trust that root won't read your ticket file
(either because nobody can get onto the machine while you're on it, or
because it's physically secure and the sysadmins aren't jerks), and if
the file's permission bits are 0600 (as the kerberos file credentials
cache library ensures), then there's no way that somebody other than
you can read it. If you don't trust root, you shouldn't leave a
ticket file on that machine.
_MelloN_
--
Ted Lemon Wells Fargo Bank, Information Protection Division
mellon@ipd.wellsfargo.com +1 415 477 5045
