(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/sudo > 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 […] 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 “this will require changes to your deployment”). > 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’s 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… > 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.
