On Fri, Jul 25, 2003 at 08:43:20AM -0500, Steve Greenland wrote: > On 24-Jul-03, 17:56 (CDT), "Dwayne C. Litzenberger" <dlitz@dlitz.net> wrote: > > On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: > > > Please don't. Is there *any* reason why defaulting > > > TMPDIR=/tmp/<username> is inferior to TMPDIR=/tmp? > > > > Systems with large numbers of users (and normally use, for example > > /home/u/username), and filesystem which doesn't like large numbers of > > entries quickly might have performance problems. > > In which case, having all the files in /tmp is likely to be worse. Not necessarily. With the current /tmp system, the only directory entries that are created are the ones that are actually needed at any given time. If we switch to /tmp/username, then there will be a directory entry in /tmp for *every user* who ever logs on. > Look, we're talking about defaults here. Defaults are not suitable for > all situations, but simply the best average choice. Very large (and > very small) systems will always have to make adjustments to suit their > particular needs. It's part of the deal of running a large system. But > for the majority of Debian users, we should pick the best option and not > bother them about it. > > Or, for all I care, we can default to /tmp/u/username. Just don't bother > me about it. I'm not trying to start a flamewar. You asked "Is there *any* reason why defaulting TMPDIR=/tmp/<username> is inferior to TMPDIR=/tmp?", I answered, and now you're being hostile and dismissive. > > And then there's the issue of making *really sure* that /tmp/username > > always exists and has the correct permissions, > > Please follow along. We're talking about automating this in a PAM, which > would create the directory and set TMPDIR. I *am* following along. Only doing it in PAM will probably not be sufficient. Consider the following scenario: - Bob logs in. /tmp/bob is created - Bob leaves his terminal xlocked for a week - in the meantime, tmpreaper cleans up /tmp/bob - Mllory creates a new /tmp/bob, allowing for later attacks - Bob comes back and runs some shell script he wrote (under the assumption that /tmp/bob would always be safe -- something which would not have happened with the regular /tmp) - Mallory executes a symlink attack Incidentally, I just installed libpam-tmpdir, and I found out that it actually handles this much more intelligently than we thought (the above attack is actually not possible with libpam-tmpdir, although Mallory could still create his own "/tmp/user", which would interfere with libpam-tmpdir's operation.) As someone else mentioned in this thread, libpam-tmpdir creates a single "/tmp/user" and "/tmp/user/$uid/". If "/tmp/user" already exists but with the wrong permissions, it fails. Oddly, it doesn't seem to set the environment variables properly when using "su", though it seems to be creating the correct directories. But neither does pam_env.so (anyone know why?). -- Dwayne C. Litzenberger <dlitz@dlitz.net> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information.
Attachment:
pgpA4t4o3Uys4.pgp
Description: PGP signature