Re: qemu-user viability

On 23.08.2025 21:17, Thorsten Glaser wrote:
> On Sat, 23 Aug 2025, Michael Tokarev wrote:
> 
>> What are we talking about?  I don't understand.
> 
> About this:

Can you read my whole question instead of just the top of it?
This is impolite when you skip whole my explanation.

> prompt> chroot --userspec=uname:gname /path/to/chroot /bin/sh
> chroot> do something
> chroot> sudo do something else

This relied on an equivalent of your /bin/sh being suid-root.
No, this isn't going to work, and nope, there's no alternative
or user-settable knob to turn it back on.  It never supposed
to work this way in any sense of security.  For this particular
workflow you have to find another way doing it, for example:

prompt> chroot --userspec=uname:gname /path/to/chroot /bin/sh
chroot> do something
chroot> exit
prompt> chroot /path/to/chroot do something else

> What part of that ↑ precisely do you not understand?

I wrote my complete question in my previous email.

I don't understand why you urge to return suid-root to your
/bin/sh.  It should not be there in the first place.
This was my question: I don't understand why you repeatedly
ask to make a binary suid-root, a binary which never supposed
to be suid-root, ever.

> And about this:
> 
> prompt> cowbuilder --create --debootstrapopts --arch=foreignarchname
> prompt> cowbuilder --build somepackage.dsc
> 
> Where somepackage’s Build-Depends are expected to work as normal,
> including when they’re suid/sgid.

You're free to implement some subsystem where this is possible to do.
Perhaps with the help of kernel, to isolate binfmt_misc interpreter
credentials from the binary it is running.  Also, qemu-user memory
model should be rewritten, to separate guest and qemu user spaces
(this will solve a lot of other issues too).

At this time, /bin/sh is not supposed to be run suid-root.  It is
not even perl (suid-perl) which at least tried to filter environment
and whatnot.

Thanks,

/mjt