[debian-mysql] Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Simon McVittie]

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 <otto at 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