Russell Coker <russ...@coker.com.au> writes: > On Sat, 11 Feb 2012, Russ Allbery <r...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipjeq99j....@windlord.stanford.edu
