On Nov 13, Simon McVittie <s...@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

Reply via email to