On Fri, 6 Sep 2024 10:37:26 +0300 Michael Tokarev <[email protected]> wrote:
04.09.2024 13:45, Simon John wrote:
> Package: qemu-system-common
> Version: 1:9.0.2+ds-7
> Severity: normal
>
> Dear Maintainer,
>
> From the "qemu (1:9.0.2+ds-2) unstable; urgency=medium" changelog:
>
> * move helper binaries (qemu-bridge-helper, virtfs-proxy-helper,
> vhost-user-gpu) from usr/lib/qemu to usr/libexec/qemu
>
> Can we not do this until tools like virt-manager and virsh are changed, as now we have this silly 10 second delay.
Oh. I didn't think about this. I somehow assumed all this stuff is
internal to qemu and not used by the outside world (it is in libexec
for a reason anyway). Now when you raised this issue to me, I think
the move was wrong to begin with.
Well if it were just people calling it from scripts it would make sense,
but it seems like the major tools have it hardcoded.
As it is nobody is seeing the message in your scripts ;-)
Yes, it is about LFS compliance, but not breaking things has a higher
priority.
Well it's not broken, but it could appear that way (10secs is a long
sleep!) I managed to figure it out as i noticed the filesize was tiny so
look at the script.
Where the 10 sec delay comes from, anyway? Ah. It is my script, the
wrapper, vhost-user-gpu. Yeah. So I did think about other usages.
Yes, this definitely needs a review. Thank you for bringing this
issue up.
> Not sure how recommending users "update their scripts" helps when the main
packages that use them aren't being updated.
Well, the need to update the scripts is already quite annoying.
It does seem like /usr/libexec/qemu has been the path for quite some
time, if i remove /usr/lib/qemu, virsh gives me:
error: 'qemu-bridge-helper' is not a suitable bridge helper: No such
file or directory
However if I copy /usr/libexec/qemu/qemu-bridge-helper to /usr/lib/ then
it finds it fine.
Looking at the libvirt source most routines check a whole bunch of
locations but the bridgeHelperDirs const is not set to use
/usr/libexec/qemu/
https://github.com/search?q=repo%3Alibvirt%2Flibvirt+lib%2Fqemu&type=code
So maybe nuke both qemu subdirectories and move the scripts to /usr/lib/ ?
> For now I'm having to delete the helpers in /usr/lib/qemu/ and create symlinks to the versions in /usr/libexec/qemu/ so why don't we symlink the whole
> directory or better still update qemu-system-gui, qemu-system-common and virtiofsd to use the new path?
virtiofsd is a different matter though - since it is not part of qemu
anymore and ships in a separate package with separate .json file
telling where the binary is.
Ah yes I see virtiofsd is already a symlink not one that i made.
Although looking at the code search above it seems the apparmor profile
is also expecting that to be in /usr/libexec/ not /usr/libexec/qemu/
What do you mean
> Similar to removing the setuid bit on qemu-bridge-helper, we need a way to override/prevent this on upgrade using dpkg as you can't make a symlink
> immutable:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765936
Yes, this is a 10 years old bug which should now be revisited at least.
Back at the time - especially since I dealt with network interfaces and
security back then - it definitely looked unsafe to keep suid bit on
qemu-bridge-helper. Now quite some things has changed, and it looks
like it was only me in the world who think it's not good to have it
suid to root.
Well I'm with you on the security issue, however:
a). there is no real alternative (maybe capabilities).
b). it's still better than running the whole thing as root.
c). the exposure can be "managed" using /etc/qemu/bridge.conf
And yes, you're absolutely right here, the move to libexec/ breaks
the workaround for lack of suid bit on q-b-h in debian. This is
another something which I didn't think about when moving things.
Yup - the u+s workaround only works if you remove your script and
recreate as symlinks.
If we get rid of the need for symlinks we can chattr +i the helper and
not have to do it every time you give us a new package mwahahaha ;-p
I'll take a look at both of the issues.
Thank you once again!
Thank you for maintaining these packages and being open to suggestion.
Most of us aren't up to the task, but bug reports are a way everyone can
contribute - especially if they're acknowledged.
--
Simon John
