* Robie Basak <robie.ba...@ubuntu.com> [221113 14:15]: > On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote: > > On Nov 13, Robie Basak <robie.ba...@ubuntu.com> wrote: > > > > > This seems inconsistent to me. Where is the expectation that TMPDIR must > > > be unset if dropping privileges coming from? Obviously for users of > > Where is the expectation that $TMPDIR is writable by any user but the > > current one? > > I do not believe that it is expected that if a user creates a directory > > and points $TMPDIR to it then they also have to make it sticky, so this > > has nothing to do with libpam-tmpdir. > > I understand the traditional semantics of TMPDIR to be exactly the same > as /tmp. So that includes the sticky bit, or at least behaviour that is > equivalent under all circumstances. Or, alternatively, that someone who > sets TMPDIR without setting the sticky bit is certain that it will be > used in a way that does not rely on that.
This is an incorrect assumption and may be what is driving your resistance to others' guidance on how to resolve these bugs. /tmp has world-writable, sticky-bit semantics specifically because it was necessary in order for the system to give a single _common_ place where all users could write temporary files, not because a temporary directory for a given process needs those semantics. TEMPDIR, on the other hand, is for _specific_ cases, and can have whatever semantics are appropriate for the environment in which it is set. TEMPDIR is specifically for use when /tmp has properties that are not appropriate for a process for any reason. The inappropriate property may be available disk space, inappropriate permissions (privacy), or anything else. When TEMPDIR is set, you specifically cannot assume that it is world-writable or has a specific amount of disk space. Also, you cannot count on automatic cleaning of the TEMPDIR directory, while you can with /tmp (at some indeterminate point in the future). I think Simon's analysis is the most thorough, well-thought-out, and technically correct that I have seen in this thread. His reasoning should be used to determine how these bugs are resolved. ...Marvin