qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update)

(Cc porters, for the arches where some buildds use qemu-user)

On Sat, 23 Aug 2025, Michael Tokarev wrote:

>> Does this entirely break things like running sudo within a
>> qemu-user-emulated chroot (or buildd/cowbuilder/schroot)?

> It discontinues elevating (changing) privileges using qemu-user binfmt
> handler.  Things like /foreign/chroot//bin/su and /foreign/chroot/bin/sud=
o
> does not work anymore.  If you run sudo /foreign/chroot/bin/bash,
> your bash will continue run as root under qemu-user, as before.

But the use case is:

prompt> chroot /foreign/chroot su - user
chroot> do something
chroot> sudo do something else   # this step
[=E2=80=A6]
chroot> exit

This needs to work, or at least be enablable (with a documentation
in at least README.Debian, with a NEWS.Debian entry pointing to it
saying precisely how, not vague =E2=80=9Cthis will require changes to your
deployment=E2=80=9D).

> There are no alternatives - qemu is unique in this regard.  And
> it has never been designed for this usage.  What we had for 15+
> years, unnoticed, is like `chmod u+s /bin/sh`, which is never
> supposed to be used like this.

Perhaps, but there=E2=80=99s shades in between.

> If you rely on suid/sgid *foreign* binaries, that's where the
> problem lies.

Yes. People expect to be able to run foreign-arch chroots.
Entire buildd setups partly rely on this, too=E2=80=A6

> I'm sorry if you disappointed you, but here's how things work.

That is a bad cop-out.

> As stated in the announcement, if you relied on this feature,
> you have to rework your setup.

And that is both too vague and not in README.Debian so that
people installing qemu-user later can find that.