-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2013 08:08 PM, Lennart Poettering wrote: > On Mon, 29.07.13 23:56, David Woodhouse (dwmw2@xxxxxxxxxxxxx) > wrote: > >> On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote: >>> So, why don't you revert to using /tmp then? >> >> The problem with /tmp is that if you want predictable filenames >> for the storage, you open yourself to a denial-of-service attack >> where another user can create a file with the same name. > > Well, but that's not unsurmountable, just pick a randomly named > directory in /tmp and make sure to have a symlink: > > ln -s /tmp/krb.XXXXXX "$HOME/.krb-`cat /etc/machine-id`" > Picking a random name brings us back to one of the original problems we needed to solve: random names make life *miserable* for daemons like GSSD that need to find the appropriate credentials for a user. Right now, it is forced to check every file (whose name corresponds to a certain pattern) in /tmp until it finds one that is still valid and it uses that to set up credentials. This is highly error-prone (for example, you might have two caches in /tmp, one that has eight hours of useful life left and one that has 30s, but if the 30s one is found first, that's the one that will be used). That's not even including the various exploits that might be present (though that's a well-investigated case). Moving somewhere that we could safely use a well-known name was a major step forward. > to give it a stable, machine-local name. That's more or less what > PulseAudio did in absence of XDG_RUNTIME_DIR in order not to be > vulnerable to namespace attacks but still having a stable, > machine-local place to put runtime objects. > > Lennart > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH3srkACgkQeiVVYja6o6PWWwCfcAkL0dJKxxv/mEnQSm2NlQOo YAYAnA/vGs/+G6CKS0vtEOXBpXJpKYL6 =RB0f -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
