Comment 42 for bug 1913421

Hi Dan,

> Ok, so I know I should have complained (more) in the Debian bug, earlier.
> It's been merged already. This is just about backporting.
...
> 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.

Please do not be concerned, we do this because we want to have a discussion
right. I appreciate any feedback, even if I might be of other opinion.
If not I could have uploaded things right away :-)

> First, let me recap what the point of all this is
> ...

I agree to the general problem statement, but many of the derived assumptions
are unfortunately not that easy :-/. Let me explain.

The solution we have right now in /run/qemu is not out of thin air:
- that path came up as best place in a security review
- and it was upstream discussed and agreed
- and after that agreement the apparmor isolation was adapted
  to allow that as the paths to do so are rather restrictive
- the mount unit now solves the issue of noexec and at
  the same time provides an opt-out mechanism

To help everyone getting more context of the past discussions, let me add a
few fragments of those:
 1. maintainer scripts should not add files in /usr/lib that are not listed
    as owned by the PKG (conffiles are fine and files a dpkg -L will list
    are fine, but others are discouraged)
 2. If we change the path to something else now we loose the worth of the
    upstream review, maybe another path has other drawbacks we just do not
    yet know
 3. any path other than the original one in /run/qemu/$ver will need to also
    modify libvirt and essentially introduce a versioned dependency. That
    is messy and to be avoided as wel.

> ...
> quick manual tmpfs mount without noexec at /run/qemu
> ...

While I admit that a mount unit is complexity, the suggestion of a manual tmpfs
is OTOH very intransparent and doing so is discouraged.

Then also SRU != new:

Finally we have shipped Variant #1 (minus the now added extension to handle
the noexec) already. Therefore in the SRU spirit we must retain that behavior
as an admin could e.g. handled himself that /run/qemu isn't noexec and now
relies on it. Not saving it there anymore would break them.
And if /run/qemu has to stay we can as well just fix it via the mount unit.

I hope I was able to outline why the mount unit approach - despite its initial
appearance - is actually the less complex one for the current situation.
I knew and can understand that you like the tmpfiles.d approach more, which is
why I haven't killed it in discussions as it is a "fair contender"
The .mount approach does:
 - retain the module save path (for admins that use it already)
 - does not imply another SRU to libvirt for apparmor
 - sticks to the upstream agreed and security reviewed paths
 - does not violate putting files in /usr/lib not owned by .deb's