Comment 20 for bug 1847361

In the discussion so far the opinions mostley leaned to "restrict it per policy" of some sort.
But I was continuing to wonder if we could not help users with a rather minimal change to avoid getting those issues.

This should really not be awkward, everyone e.g. wants to avoid building special packages - a version per build in the package name to be coinstallable looks bad. At the same time the dependencies would be odd as well, as you want them uninstallable, but only after e.g. a reboot.

Therefore as mentioned before the probably easiest way out is to use /tmp or even better /var/run as a temporary place which also will be auto-cleaned on a host reboot.

Considering that packaging has scripts that run on removal, and distributions could opt-in by placing the "old" modules under /var/run/...//$buildid/*.so that way qemu only needs to look for that path as fallback (should be a small change).

The full path to /usr/lib/x86_64-linux-gnu/qemu/ usually is "drwxr-xr-x root root".
There the modules are currently stored.
The dir /run (and below) is the same so the seucrity impact of "but people could place .so files there" isn't different to today where people that can get root permissions can modify files in the current path qemu looks for loading shared objects.
CC: lets add some security people still to give this an extra thought (TODO add Seth/Mdeslaur)

The DIR could even be set via an environment variable:
197 search_dir = getenv("QEMU_MODULE_DIR");
198 if (search_dir != NULL) {
199 dirs[n_dirs++] = g_strdup_printf("%s", search_dir);
200 }

So if we could set this ENV properly by default we could even go without a change to qemu.
Currently the ENV of a qemu process is:
$ cat /proc/3077/environ
LC_ALL=CPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
HOME=/var/lib/libvirt/qemu/domain-3-focal2
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-focal2/.local/share
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-focal2/.cache
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-focal2/.config
QEMU_AUDIO_DRV=spiceroot

So the path isn't used already.
But the environment is cleared and constructed by libvirt, we can't easily "modify" it.
=> https://libvirt.org/drvqemu.html#qemucommand

That is a bit of a set-back for a packaging-only change.
But it provides a nicer workaround as users could run with a custom:
  <qemu:commandline>
    <qemu:env name='QEMU_ENV' value='/my/old/so/path'/>
  </qemu:commandline>
And copy the .so files before upgrade to /my/old/so/path.
Never the less this isn't good for multiple upgrades in a row and it isn't good to automate it for the user.

We'd need an ID that packaging (cleanup scripts) and qemu (module load path) know both about.
The packaging knows a distro specific version like 1:4.2-3ubuntu1 while the binary only knows the DSO_STAMP_FUN_STR which is a sha hashed qemu_version+pkg_version.

For example in 1:2.11+dfsg-1ubuntu7.23 that for me was
0000000000001d10 <qemu_module_dummy@@Base-0xf0>:
    1d10: 48 8d 3d 19 01 00 00 lea 0x119(%rip),%rdi # 1e30 <qemu_stamp_c3f82e4206b8ff79fa97faa8eba4807efa7c1397@@Base+0x20>

That is known:
$ qemu-system-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23)

But it also cat's the full configure script and then generates a sha.
Replicating that in postrm or at build time sounds too brittle to rely upon.

Back to a hopefully small change for qemu ... it could include all of a certain path iterating?
pkgversion would be good, so lets see if we can get that from the code.

"2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23)" is in var "QEMU_FULL_VERSION"
QEMU_PKGVERSION contains just the inner part "Debian 1:2.11+dfsg-1ubuntu7.23"
This will still need to strip spaces and special chars which also is ugly but I don't see a better ID to use atm.
Let us try to go with that ...