On Nov 13, Simon McVittie <smcv@debian.org> wrote: > I think you can both be right. The symptom here is a maintainer script > failing, but if I'm understanding Marco's argument correctly, he's > saying that the root cause is that when you switch between execution > environments, not all of the environment variables inherited from the old > execution environment are appropriate for the new one. (A similar thing > can happen for other inheritable process parameters like resource limits.) Yes, but this is a general issue and not relevant for this specific case. Because let's consider an environment in which: - there is no relevant elevation of privileges, so discussions about what should libpam-something, sudo, etc... do are not applicable - the root environmente legitimately has TMPDIR=/tmp/root-only/ mode 700 - a maintainer script does something as an unprivileged user which needs to access $TMPDIR so you correctly noted that: > If the maintainer script is *dropping* privileges from root down to a > system user, then I think the maintainer script is/should be responsible > for doing that privilege drop in a way that works - but ideally the > maintainer script should be delegating that responsibility to a common > tool rather than open-coding it itself, either by launching a one-shot > system service that the init infrastructure can run in a predictable > execution environment, or using a common privilege-level-switching tool > like runuser, su or sudo, or using an IPC-based "run this command in a > more controllable enviroment" tool like systemd-run. And I think that it would be wrong to have dpkg generally unset $TMPDIR, because if root sets it then it would be reasonable to expect that also dpkg and the maintainer scripts use it (as long as they are not dropping privileges). -- ciao, Marco
Attachment:
signature.asc
Description: PGP signature