Robie Basak <robie.ba...@ubuntu.com> writes: > This seems inconsistent to me. Where is the expectation that TMPDIR must > be unset if dropping privileges coming from? Obviously for users of > libpam-tmpdir that's a problem. But in the default case, it's something > that would be entirely reasonable to inherit through a drop of > privileges, for the same reason that I think you find that setting > TMPDIR for maintainer scripts to use would be useful.
You were asking what changed from the historical behavior of UNIX. This, right here, is what changed. As you note, historically UNIX uses a world-writable /tmp and assumed basically everything on the system would use it. Once UNIX started caring more seriously about security, we discovered this came with a whole host of security problems. Most of those have been tediously fixed over the years, but the fixes can be quite complex and to this day we continue to see new software that gets it wrong, because it's very easy (particularly when writing standard C) to not use the right combination of file name randomization, O_EXCL flags, permissions, and so forth to mostly make this safe. Accordingly, private /tmp directories have become increasingly popular. There are several different mechanisms to use them; the mechanism isn't very important. But they often use $TMPDIR since that variable is widely supported. Because the security problems with /tmp happen whenever two users with different privileges use the same directory, private /tmp makes just as much sense for root (if not even more sense, since root is at inherently higher risk) as it does for any other user. So it's not surprising to start seeing root users with private /tmp, which will inherently require *something* to change when dropping privileges from root and needing to use a temporary directory. The whole point of private /tmp is that every separate permission domain uses a separate directory for temporary files that's restricted to just that domain. Obviously, private /tmp is optional, but it has very real defense in depth security properties because shared /tmp is a surprisingly tricky security challenge. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>