Re: severity for bugs in ignoring TMP/TMPDIR?
Russell Coker <russell@coker.com.au> writes:
> On Sat, 11 Feb 2012, Russ Allbery <rra@debian.org> wrote:
>> Sometimes there are no good options other than using O_EXCL with a
>> predictable name because the name is used as a rendezvous point. This
>> is the case in some (non-default) configurations for Kerberos tickets,
>> for example.
> Why would /tmp be a good option for a rendezvous point?
For Kerberos ticket caches, because it's world-writable (so all users can
use the same location), local to the system, automatically cleared on
reboot, and ideally isn't written to disk (which makes it more secure
against some attacks).
To understand the issue, the program that you want to look at is rpc.gssd.
These days, I think it uses a more sophisticated algorithm that copes with
random data in the file names, and some of these issues are slowly being
fixed, but it requires additional work to implement the directory scanning
algorithm rather than just looking for krb5cc_<uid>.
Obviously, no one is particularly happy with this, and the long-term
direction is towards doing something else with Kerberos ticket caches.
The Linux keyring cache has some nice properties, as does KCM. But these
things are slow to change, and applications that create Kerberos ticket
caches have to be conservative so that they can be used. Usually the
location is transmitted via the KRB5CCNAME environment variable, but
obviously this doesn't work with rpc.gssd. (AFS, unlike NFS, has always
used something very similar to a kernel keyring ticket cache.)
libpam-krb5 creates ticket caches with random names that include the UID
by default, but it supports a set of configuration options for choosing
the ticket cache name, and I know of some people who do use more
predictable ticket cache names because it makes some things easier.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: