Ok, so I know I should have complained (more) in the Debian bug, earlier. It's been merged already. This is just about backporting.
However, reading the merge requests just makes me...itchy. First, let me recap what the point of all this is: When qemu is upgraded from version X to version Y, the loadable block modules for version X need to be saved somewhere, in case an instance already running with version X later needs to load a block module (so it can attach a volume). So we need to save the version X block modules somewhere that existing instances can load from, which means it needs to be some fs that isn't noexec. Also, since we're guaranteed that all instances running version X will be gone after a reboot, we want the place we save version X block modules to be transient - it should disappear automatically after a reboot. That's it. We don't need anything else. One proposed method was, at time of uninstalling version X, to mkdir a new directory in the normal filesystem to store the version X block modules, and to add a generic tmpfiles.d config that would clean out this temporary-storage location on each boot. That was dismissed in the Debian bug due to the Debian qemu maintainer using a completely read- only root filesystem, meaning the version X modules wouldn't be cleaned up on boot. The previous approach was to mkdir a new subdirectory under /run and put the version X modules there. The problem with that is /run is typically mounted with noexec, so qemu isn't able to load executable modules located under /run. This approach now adds an entirely new systemd mount unit to mount /run/qemu without noexec, and then store version X modules there. This new mount unit must be managed in the maintainer scripts, including installing it, reloading systemd, enabling it, starting it, and leaving it mounted all the time, for each boot. Personally, I find all this more than overcomplicated. Let's remember what we need to do - save a few files onto a filesystem that isn't mounted noexec, and that will be gone after a reboot. And that needs to happen *only* when the qemu package is removed or upgraded, not all the time. Even adding the additional directory to load modules from and the tmpfiles.d conf felt like it was overcomplicating things to me; having to add an entirely new mount unit and make sure it's properly running after install and also after boot... I really don't want to *further* overcomplicate all this, but at the same time I really don't feel like i can give my +1 to the merge requests. Personally, I wouldn't have done it that way in Debian. If we don't want to 'mkdir -p /usr/lib/@ARCH@/qemu/VERSION_X/ ; cp /usr/lib/@ARCH@/qemu/block*.so /usr/lib/@ARCH@/qemu/VERSION_X/' in the postinst script (along with the tmpfiles.d conf to remove them at boot), because some users might leave their root filesystems read-only except during package upgrades, then fine, let's just 'mkdir -p /run/qemu/VERSION_X/ ; cp /usr/lib/@ARCH@/qemu/block*.so /run/qemu/VERSION_X/' instead (which avoids the need for any tmpfiles.d conf) and throw in a check for 'noexec' in the postinst and actually do a quick manual tmpfs mount without noexec at /run/qemu (or some subdir) if needed. No mount unit we need to install and manage and tie into the boot transaction so it's always mounted. Maybe I'm just making the backporting more difficult by complaining about it being more complex than should be needed for the relatively simple operation we need to do. So like I said, I can't give my +1 to the backports, but at the same time I don't want to block anything. If it works, and someone else from the server team +1's them, don't let me stop this. We need to do something for this bug. So, I'll mark myself as abstaining from the merge request reviews. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913421 Title: Load of pre-upgrade qemu modules needs to avoid noexec To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1913421/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
