Hello, Pardon me for tweaking the subject line; "qemu-user lost its entire viability" is not something I'm directly addressing, but I nevertheless feel this doesn't assess non-chroot-related use cases and object to proliferating that idea.
I also concede I haven't been following the discussion particularly closely as it is happening very quickly but I nevertheless want to point out an option that I haven't seen mentioned: how about using a low-priority (i.e. not shown by default) Debconf question to allow configuring the old behavior? I believe this is an approach used by some network diagnostic tools in Debian (Wireshark and friends perhaps?). For example a tool that's rarely used and is only manually invoked by an experienced sysadmin might not have a compelling need for a set-UID bit or e.g. CAP_NET_RAW set, but for other respectable use cases such as automation, or when other security enhancements are in place, or on systems that are not mission-critical, an administrator/user may decide incurring a risk is acceptable or advances "the greater good". Higher-priority Debconf questions are often used when a decision must be made on package installation in order for it to be useful at all, or if a decision must be made that trades off expected behaviors, such as applying Debian defaults versus upstream defaults when real-world use can benefit from either. In this situation, a lower-priority Debconf question seems like a great tool: • Debconf can be "primed" such as with debconf-set-selections or Debian Installer preseeding to know what the user wants just before, or even well in advance, of the package being installed. • This is a matter that gets more scrutiny from Debian users and developers than upstream, can't be specified in a hypothetical platform-agnostic QEMU configuration file well, and could benefit from integration with Debian's way of doing things as they pertain to the kernel. That is to say, Debconf is a great means to this end. • The various Debconf backends, such as the LDAP backend, can help toggle the former behavior in settings like buildd networks or clusters, even irrespective of when (or if) qemu-user is installed. • Control freaks like myself who set the default Debconf prompting priority very low can make a conscious decision such as this when there is one to be made. • We are cognizant that restoring the old behavior is one of the more likely things someone troubleshooting or tinkering with qemu-user will want to do. • Restoring the former behavior is more programmatic and semantic: we know that asking users to dig deep into documentation and learn eccentricities of Linux kernel binfmt setup wouldn't be a great use of their time. This would-be-meticulous setup and means-to-the-end can be safely done "behind the scenes" as long as we inform the user what the risks are and what the benefits are. That's what real users really care about and with a sensible prompt we can do that. Copying and pasting directions from some README file that might only be found by an experienced treasure hunter is needlessly burdensome. Users can be discouraged from introducing harmful security holes when needed by informing them, not through artificial or contrived obstacles. • The option can have a default which, if nothing else, declares "Here's how qemu-user behaves now, but it doesn't have to be this way. You can learn more if you want to, or you can take Debian's informed, secure, and sensible default and be happy." In conclusion, let's take a look what tools we may have at our disposal for an outside-the-box solution. I hope I found a candidate, and if using Debconf is not the right way to go here, we'll be all the better with that being an informed judgment call. Thanks, John
signature.asc
Description: This is a digitally signed message part
