On Sun, 13 Nov 2022 at 11:38:08 +0000, Robie Basak wrote: > On Sun, Nov 13, 2022 at 02:21:58AM +0100, Marco d'Itri wrote: > > On Nov 12, Otto Kekäläinen <o...@kekalainen.net> wrote: > > > Instead of manually trying to manage TMPDIR env variable in various > > > places, we should have a standardized way to run maintainer scripts in > > > clean shell sessions that have all env variables set automatically > > > correctly. > > > > This is not about maintainer scripts, but about programs which change > > the UID without sanitizing the environment. > > No, it's absolutely about maintainer scripts, since that's the bug > reported, and the specific fix suggested implies that all relevant > maintainer scripts need changing.
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.) The specific bug we're discussing in mysql-server-8.0 seems like it potentially has two separate privilege transitions: one elevating privileges from a sysadmin up to root (via `sudo apt upgrade` or equivalent), and one dropping privileges from root down to a system user to run a preparation step in the maintainer script. I think some of the people replying to the thread on -devel might be conflating those two privilege transitions, which means we end up talking at cross purposes because a valid point made about one transition can be invalid for the other. For the privilege elevation from a sysadmin up to root, this could in principle be addressed anywhere within the inheritance chain: your shell -> sudo/su/pkexec -> apt -> dpkg -> maintainer script -> ... but I think it's reasonable to say that it's sudo/su/pkexec/... that is doing an unusual change to the execution environment, so it should also be sudo/su/pkexec/... that is responsible for making sure the new execution environment is internally consistent. Making each maintainer script responsible for solving this problem for itself would scale poorly, so if someone's suggested fix involves changing all maintainer scripts, I'd very much prefer to look at whether that can be avoided. 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. smcv