This bug was fixed in the package libvirt - 5.0.0-1ubuntu2
---
libvirt (5.0.0-1ubuntu2) disco; urgency=medium
* Implement further apparmor rules for usage of gl enabled
graphics (LP: #1815452)
- d/p/ubuntu-aa/lp-1815452-more-gl-rules.patch
-
Fix for this and bug 1817943 now uploaded to Disco - lets see how it
migrates.
GL seems still shaky in different use cases aside the most default path
- therefore I'm not making it easier to use it on older releases -
therefore no SRU of the change.
--
You received this bug notification because
Opened a new bug as requested -
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1817943
Thanks for the detailed explanation on libvirtd's limitations in regards
to defaults. I'm using virt-manager, which looks like it could be
pursued for that seperately.
--
You received this bug
> I tried getting this working on my nVidia card, but wasn't able to.
Hi Brian, thanks for the test.
The gl features are still new and I enable them one by one (i915, mdev
usage, nvidia).
It is good to know that there are more issues lurking, I'll at some
point do the same tests and then try to
Comment #18 hit the wrong bug - sorry - removing the B/C bug tasks.
This is intended for Disco and later only.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815452
Title:
more apparmor denials for
I tried getting this working on my nVidia card, but wasn't able to.
Added abstractions to local/abstractions/libvirt-qemu.
/proc/modules r,
/proc/driver/nvidia/ r,
/proc/driver/nvidia/** r,
/usr/share/egl/ r,
/usr/share/egl/** r,
/sys/devices/** r,
/sys/devices/ r,
/dev/nvidiactl
Unless the security Team really dislikes the idea of opening it up I'd
want to at least SRu this change to Bionic - further back I'm not so
sure (the further we go back the less hardening/fixes the interface will
have).
Adding bug tasks.
** Also affects: libvirt (Ubuntu Cosmic)
Importance:
I checked Suse's config for the qemu user it is literal "qemu" and it
has "/" set as home dir. But I must admit I'm not liking to add /.config
to the rules, therefore I'm skipping this rather unspecific path from
the rules for now.
--
You received this bug notification because you are a member
Testable PPA for Disco in [1] and the upstreaming of the changes started
at [2]
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3644/+packages
[2]: https://www.redhat.com/archives/libvir-list/2019-February/msg00704.html
** Changed in: libvirt (Ubuntu)
Status: Triaged =>
Ok, first revision of the patches is complete, submitting upstream for
review ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815452
Title:
more apparmor denials for opengl usage
To manage
After consulting the apparmor people, HOME isn't a users home dir but the list
of all defined homedirs in /etc/apparmor.d/tunables/home
Eventually this would only catch classic home dirs in /home by
@{HOME}=@{HOMEDIRS}/*/ /root/
But not any special ones like this.
Lets add the path we need then
I thought it is the owner attribute, but the following works:
owner "/var/lib/libvirt/.cache/" w,
So it must be the resolution of @{HOME} which fails
Which is odd as I thought it worked for
owner @{HOME}/.drirc
But I realized this was a rule I copied over that isn't needed (dropped now).
I'm not entirely sure if the pathing for the XDG things is correct in libvirt.
The usual rule from mesa [1] would be:
owner @{HOME}/.cache/ w, # if user clears all caches
But that does not work as user is libvirt-qemu which has a home in
/var/lib/libvirt
libvirt-qemu:x:108:135:Libvirt
I confirmed two times now, even with an explicit rendernode set it will
try to open the dir as well hitting
[83520.947120] audit: type=1400 audit(1549973902.951:298):
apparmor="DENIED" operation="open" profile="libvirt-2f6bde7c-1d3d-498a-
b96c-8920f165fa4c" name="/dev/dri/" pid=8268
Well you don't need my rule for Fifa98-KVM obviously, but all the rest
:-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815452
Title:
more apparmor denials for opengl usage
To manage
The detection with virt-aa-helper was fixed by the /dev/dri read to
virt-aa-helper and I got this rule:
"/dev/dri/renderD128" rw,
Yet as we learned above, we need way more.
I need to discuss:
- which ones we want to add statically
- which ones we want to add after gl is detected
- what pathing
** Attachment added: "virt-aa-helper - extra rules I needed for GL to work"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452/+attachment/5237720/+files/usr.lib.libvirt.virt-aa-helper
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: "libvirt-qemu - extra rules I needed for GL to work"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452/+attachment/5237719/+files/libvirt-qemu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hmm, also hit virt-aa-helper deny like this:
apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/dev/dri/"
pid=17413 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Guest XML as defined by virt-manager that does not trigger the GL
detection in virt-aa-helper
** Attachment added: "with-gl-from-virt-manager.xml"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452/+attachment/5237703/+files/with-gl-from-virt-manager.xml
--
You received this
Denies/log entries and their related solution:
XML snippet generated:
(no rendernode set and no other gl reference got added).
Generated profile (did gl detection trigger?):
Has no references to rendernodes that should be added by virt-aa-helper
guest log fails as
After one more round of manual fixes (for now) I got these:
apparmor="DENIED" operation="open"
profile="libvirt-2f6bde7c-1d3d-498a-b96c-8920f165fa4c" name="/dev/dri/"
pid=17275 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=108
ouid=0
apparmor="DENIED" operation="open"
Note: as intended an unset rendernode (to libvirt) gets specified in
commandline (to qemu)
-spice port=0,disable-ticketing,image-
compression=off,gl=on,rendernode=/dev/dri/renderD128,seamless-
migration=on
So we'd expect virt-aa-helper to trigger in the same case.
--
You received this bug
until a proper fix for virt-aa-helper is available I hardcoded the
rendernode, but still get some issues.
apparmor="DENIED" operation="open"
profile="libvirt-2f6bde7c-1d3d-498a-b96c-8920f165fa4c"
name="/usr/share/drirc.d/" pid=17033 comm="qemu-system-x86" requested_mask="r"
denied_mask="r"
24 matches
Mail list logo
