Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 13:27:04 -0600, Dwayne C. Litzenberger wrote:
> 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.
That is a reasonable question to ask. I think Dwayne has pointed out two
1- Creating per-user directories might be expensive.
2- There are some problems with the current libpam implementation.
#1 is not quite invalid, but I don't think it is the overriding concern
here. The disk used by an empty directory is negligible. Machines which
are very tiny, or have thousands of users can set up their own system.
There are a large number of insecure scripts out there, and very likely
still some applications with tmpfile holes. I don't think a minor or
probably negligible performance issue justifies leaving these problems
#2 is a reason to fix libpam-tmpdir, not to stick with a shared /tmp.
Dwayne, can you think of anything aside from those two?
> - 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
> that /tmp/bob would always be safe -- something which would not have
> happened with the regular /tmp)
> - Mallory executes a symlink attack
As Dwayne probably discovered, this would be impossible because the actual
directory is (say) /tmp/users/1001, and only root can write to /tmp/users.
> 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.
Yes, that is a problem with the current code. It is not a problem with
the general idea of per-user temp directories. There are various ways to
fix it, including
- Creating /tmp/user as root during startup before Mallory can log in
- Putting this somewhere other than /tmp -- say /usertmp, mode 711. (But
I suppose people will think it's ugly and I can't think of a good name.)
Perhaps tmpreaper could be set up not to never reap /tmp/user.
It is a little ironic that the issue of making sure /tmp/user is the
real one is exactly what I hope to avoid by moving away from 1777
> 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?).
Does su mop the environment?