On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote: > On Nov 13, Robie Basak <robie.basak@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. libpam-tmpdir breaks those semantics in a way that breaks in edge cases like the situation raised in this (and other) bug reports. So on the contrary, I think it has everything to do with libpam-tmpdir, and anything else that sets TMPDIR to something that doesn't match the traditional semantics. To be clear, if it's better that we change the semantics to improve the system as a whole, then I don't have a particular objection to that. But I'd prefer that it be done deliberately, with consensus across all developers, and be well-defined and documented. Rather than have a change of semantics exist in a multitude of individual fixes for individual bug reports that potentially end up solving the issue differently, inconsistently or incompletely, and without regard for the bigger picture (eg. if the conclusion is that it should be done somewhere other than maintainer scripts or in common tooling). There's also the risk that we swap one problem for another - for example if there are use cases which rely on maintainer scripts honouring TMPDIR, including when they drop privileges.
Attachment:
signature.asc
Description: PGP signature