[libvirt] [PATCH 0/2] further apparmor handling of opengl
Further testing with opengl enabled graphics showed that we need much more rules than we initially added. Upstream apparmor has abstractions [1][2] for the majority of what we'd need, but those are in no Distribution yet so we can't rely on them. But we can add rules "like those known ones" matching what our testing shows as needed when we add a gl enabled device. There is no overly critical access opened by this, but still we continue to only add those to the guests that have gl enabled. The most "discussion worthy" part of it most likely are the wildcards into /dev/devices/... but they are rather specific and read only - furthermore retracing those in advance starting from the rendernode most likely is rather error prone, so I went with the wildcards. Example apparmor denials can be found in the launchpad bug [3] [1]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstrac... [2]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstrac... [3]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Christian Ehrhardt (2): security: aa-helper: allow virt-aa-helper to read /dev/dri security: aa-helper: generate more rules for gl devices .../apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ src/security/virt-aa-helper.c | 20 ++++++++++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) -- 2.17.1
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But it will in certain cases e.g. if no rendernode was explicitly specified need to read /dev/dri which it currently isn't allowed. Add a rule to the apparmor profile of virt-aa-helper itself to be able to do that. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper index de9436872c..78994bcda6 100644 --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper @@ -19,6 +19,9 @@ profile virt-aa-helper /usr/{lib,lib64}/libvirt/virt-aa-helper { /etc/libnl-3/classid r, + # for gl enabled graphics + /dev/dri/{,*} r, + # for hostdev /sys/devices/ r, /sys/devices/** r, -- 2.17.1
On Tue, 12 Feb 2019, Christian Ehrhardt wrote:
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But it will in certain cases e.g. if no rendernode was explicitly specified need to read /dev/dri which it currently isn't allowed.
Add a rule to the apparmor profile of virt-aa-helper itself to be able to do that.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper index de9436872c..78994bcda6 100644 --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper @@ -19,6 +19,9 @@ profile virt-aa-helper /usr/{lib,lib64}/libvirt/virt-aa-helper {
/etc/libnl-3/classid r,
+ # for gl enabled graphics + /dev/dri/{,*} r, +
This looks fine. -- Jamie Strandboge | http://www.canonical.com
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But further testing showed that it will need much more access for the full gl stack to work. Upstream apparmor just recently split those things out and now has two related abstractions at https://gitlab.com/apparmor/apparmor/blob/master: - dri-common at /profiles/apparmor.d/abstractions/dri-common - mesa: at /profiles/apparmor.d/abstractions/mesa If would be great to just include that for the majority of rules, but they are not yet in any distribution so we need to add rules inspired by them based on the testing that we can do. Furthermore qemu with opengl will also probe the backing device of the rendernode for attributes which should be safe as read-only wildcard rules. Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/virt-aa-helper.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 8e22e9978a..46c1914f58 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -937,7 +937,7 @@ get_files(vahControl * ctl) size_t i; char *uuid; char uuidstr[VIR_UUID_STRING_BUFLEN]; - bool needsVfio = false, needsvhost = false; + bool needsVfio = false, needsvhost = false, needsgl = false; /* verify uuid is same as what we were given on the command line */ virUUIDFormat(ctl->def->uuid, uuidstr); @@ -1065,9 +1065,11 @@ get_files(vahControl * ctl) if (rendernode) { vah_add_file(&buf, rendernode, "rw"); + needsgl = true; } else { if (virDomainGraphicsNeedsAutoRenderNode(graphics)) { char *defaultRenderNode = virHostGetDRMRenderNode(); + needsgl = true; if (defaultRenderNode) { vah_add_file(&buf, defaultRenderNode, "rw"); @@ -1267,6 +1269,22 @@ get_files(vahControl * ctl) virBufferAddLit(&buf, " \"/dev/vfio/vfio\" rw,\n"); virBufferAddLit(&buf, " \"/dev/vfio/[0-9]*\" rw,\n"); } + if (needsgl) { + /* if using gl all sorts of further dri related paths will be needed */ + virBufferAddLit(&buf, " # DRI/Mesa/(e)GL config and driver paths\n"); + virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/etc/drirc\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n"); + virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " owner \"/var/lib/libvirt/.cache/\" w,\n"); + virBufferAddLit(&buf, " # Probe DRI device attributes\n"); + virBufferAddLit(&buf, " \"/dev/dri/\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/drm/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + } if (ctl->newfile) if (vah_add_file(&buf, ctl->newfile, "rwk") != 0) -- 2.17.1
On Tue, 12 Feb 2019, Christian Ehrhardt wrote:
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But further testing showed that it will need much more access for the full gl stack to work.
Upstream apparmor just recently split those things out and now has two related abstractions at https://gitlab.com/apparmor/apparmor/blob/master: - dri-common at /profiles/apparmor.d/abstractions/dri-common - mesa: at /profiles/apparmor.d/abstractions/mesa
If would be great to just include that for the majority of rules, but they are not yet in any distribution so we need to add rules inspired by them based on the testing that we can do.
Furthermore qemu with opengl will also probe the backing device of the rendernode for attributes which should be safe as read-only wildcard rules.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/virt-aa-helper.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 8e22e9978a..46c1914f58 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -937,7 +937,7 @@ get_files(vahControl * ctl) size_t i; char *uuid; char uuidstr[VIR_UUID_STRING_BUFLEN]; - bool needsVfio = false, needsvhost = false; + bool needsVfio = false, needsvhost = false, needsgl = false;
/* verify uuid is same as what we were given on the command line */ virUUIDFormat(ctl->def->uuid, uuidstr); @@ -1065,9 +1065,11 @@ get_files(vahControl * ctl)
if (rendernode) { vah_add_file(&buf, rendernode, "rw"); + needsgl = true; } else { if (virDomainGraphicsNeedsAutoRenderNode(graphics)) { char *defaultRenderNode = virHostGetDRMRenderNode(); + needsgl = true;
if (defaultRenderNode) { vah_add_file(&buf, defaultRenderNode, "rw"); @@ -1267,6 +1269,22 @@ get_files(vahControl * ctl) virBufferAddLit(&buf, " \"/dev/vfio/vfio\" rw,\n"); virBufferAddLit(&buf, " \"/dev/vfio/[0-9]*\" rw,\n"); } + if (needsgl) { + /* if using gl all sorts of further dri related paths will be needed */ + virBufferAddLit(&buf, " # DRI/Mesa/(e)GL config and driver paths\n"); + virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/etc/drirc\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n"); + virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n");
The above rules are fine. It would be nice to me slightly more specific in the mmap rules to mmap only .so files, but not a blocker.
+ virBufferAddLit(&buf, " owner \"/var/lib/libvirt/.cache/\" w,\n");
This doesn't seem to belong here and DAC is usually going to prevent it since VMs run as non-root and /var/lib/libvirt is 755. Perhaps get rid of owner and make this an explicit denial rule to silence the denial (with a code comment)?
+ virBufferAddLit(&buf, " # Probe DRI device attributes\n"); + virBufferAddLit(&buf, " \"/dev/dri/\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/drm/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n");
These are fine. -- Jamie Strandboge | http://www.canonical.com
On Fri, Feb 15, 2019 at 11:29 PM Jamie Strandboge <jamie@canonical.com> wrote:
On Tue, 12 Feb 2019, Christian Ehrhardt wrote:
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But further testing showed that it will need much more access for the full gl stack to work.
Upstream apparmor just recently split those things out and now has two related abstractions at https://gitlab.com/apparmor/apparmor/blob/master: - dri-common at /profiles/apparmor.d/abstractions/dri-common - mesa: at /profiles/apparmor.d/abstractions/mesa
If would be great to just include that for the majority of rules, but they are not yet in any distribution so we need to add rules inspired by them based on the testing that we can do.
Furthermore qemu with opengl will also probe the backing device of the rendernode for attributes which should be safe as read-only wildcard rules.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/virt-aa-helper.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 8e22e9978a..46c1914f58 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -937,7 +937,7 @@ get_files(vahControl * ctl) size_t i; char *uuid; char uuidstr[VIR_UUID_STRING_BUFLEN]; - bool needsVfio = false, needsvhost = false; + bool needsVfio = false, needsvhost = false, needsgl = false;
/* verify uuid is same as what we were given on the command line */ virUUIDFormat(ctl->def->uuid, uuidstr); @@ -1065,9 +1065,11 @@ get_files(vahControl * ctl)
if (rendernode) { vah_add_file(&buf, rendernode, "rw"); + needsgl = true; } else { if (virDomainGraphicsNeedsAutoRenderNode(graphics)) { char *defaultRenderNode = virHostGetDRMRenderNode(); + needsgl = true;
if (defaultRenderNode) { vah_add_file(&buf, defaultRenderNode, "rw"); @@ -1267,6 +1269,22 @@ get_files(vahControl * ctl) virBufferAddLit(&buf, " \"/dev/vfio/vfio\" rw,\n"); virBufferAddLit(&buf, " \"/dev/vfio/[0-9]*\" rw,\n"); } + if (needsgl) { + /* if using gl all sorts of further dri related paths will be needed */ + virBufferAddLit(&buf, " # DRI/Mesa/(e)GL config and driver paths\n"); + virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**\" mr,\n"); + virBufferAddLit(&buf, " \"/etc/drirc\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n"); + virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n");
The above rules are fine. It would be nice to me slightly more specific in the mmap rules to mmap only .so files, but not a blocker.
Ok, will do *.so for the mmaps in a V2 thanks for the hint
+ virBufferAddLit(&buf, " owner \"/var/lib/libvirt/.cache/\" w,\n");
This doesn't seem to belong here and DAC is usually going to prevent it since VMs run as non-root and /var/lib/libvirt is 755. Perhaps get rid of owner and make this an explicit denial rule to silence the denial (with a code comment)?
I was just following the denials that I saw, I also couldn't fully see the reason. I can follow your DAC argument which is correct, and in addition every instance would use the same cache which I'm not sure would be right. I'll remove the line in a v2 and replace it with the suggested denial.
+ virBufferAddLit(&buf, " # Probe DRI device attributes\n"); + virBufferAddLit(&buf, " \"/dev/dri/\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/drm/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n");
These are fine.
-- Jamie Strandboge | http://www.canonical.com
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Further testing with opengl enabled graphics showed that we need much more rules than we initially added. Upstream apparmor has abstractions [1][2] for the majority of what we'd need, but those are in no Distribution yet so we can't rely on them. But we can add rules "like those known ones" matching what our testing shows as needed when we add a gl enabled device. There is no overly critical access opened by this, but still we continue to only add those to the guests that have gl enabled. The most "discussion worthy" part of it most likely are the wildcards into /dev/devices/... but they are rather specific and read only - furthermore retracing those in advance starting from the rendernode most likely is rather error prone, so I went with the wildcards. Example apparmor denials can be found in the launchpad bug [3] Updates in V2: - add jamies ack to patch #1 - limit the mapping rules to .so files - change the .changes rule to a deny as DAC would block it anyway [1]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstrac... [2]: https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstrac... [3]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Christian Ehrhardt (2): security: aa-helper: allow virt-aa-helper to read /dev/dri security: aa-helper: generate more rules for gl devices .../apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ src/security/virt-aa-helper.c | 21 ++++++++++++++++++- 2 files changed, 23 insertions(+), 1 deletion(-) -- 2.17.1
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But it will in certain cases e.g. if no rendernode was explicitly specified need to read /dev/dri which it currently isn't allowed. Add a rule to the apparmor profile of virt-aa-helper itself to be able to do that. Acked-by: Jamie Strandboge <jamie@canonical.com> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/apparmor/usr.lib.libvirt.virt-aa-helper | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper index de9436872c..78994bcda6 100644 --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper @@ -19,6 +19,9 @@ profile virt-aa-helper /usr/{lib,lib64}/libvirt/virt-aa-helper { /etc/libnl-3/classid r, + # for gl enabled graphics + /dev/dri/{,*} r, + # for hostdev /sys/devices/ r, /sys/devices/** r, -- 2.17.1
On Mon, 18 Feb 2019, Christian Ehrhardt wrote:
+ # for gl enabled graphics + /dev/dri/{,*} r, +
+1 to include -- Jamie Strandboge | http://www.canonical.com
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But further testing showed that it will need much more access for the full gl stack to work. Upstream apparmor just recently split those things out and now has two related abstractions at https://gitlab.com/apparmor/apparmor/blob/master: - dri-common at /profiles/apparmor.d/abstractions/dri-common - mesa: at /profiles/apparmor.d/abstractions/mesa If would be great to just include that for the majority of rules, but they are not yet in any distribution so we need to add rules inspired by them based on the testing that we can do. Furthermore qemu with opengl will also probe the backing device of the rendernode for attributes which should be safe as read-only wildcard rules. Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- src/security/virt-aa-helper.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 8e22e9978a..784ee49e61 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -937,7 +937,7 @@ get_files(vahControl * ctl) size_t i; char *uuid; char uuidstr[VIR_UUID_STRING_BUFLEN]; - bool needsVfio = false, needsvhost = false; + bool needsVfio = false, needsvhost = false, needsgl = false; /* verify uuid is same as what we were given on the command line */ virUUIDFormat(ctl->def->uuid, uuidstr); @@ -1065,9 +1065,11 @@ get_files(vahControl * ctl) if (rendernode) { vah_add_file(&buf, rendernode, "rw"); + needsgl = true; } else { if (virDomainGraphicsNeedsAutoRenderNode(graphics)) { char *defaultRenderNode = virHostGetDRMRenderNode(); + needsgl = true; if (defaultRenderNode) { vah_add_file(&buf, defaultRenderNode, "rw"); @@ -1267,6 +1269,23 @@ get_files(vahControl * ctl) virBufferAddLit(&buf, " \"/dev/vfio/vfio\" rw,\n"); virBufferAddLit(&buf, " \"/dev/vfio/[0-9]*\" rw,\n"); } + if (needsgl) { + /* if using gl all sorts of further dri related paths will be needed */ + virBufferAddLit(&buf, " # DRI/Mesa/(e)GL config and driver paths\n"); + virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/etc/drirc\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n"); + virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " # Probe DRI device attributes\n"); + virBufferAddLit(&buf, " \"/dev/dri/\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + virBufferAddLit(&buf, " \"/sys/devices/*/*/drm/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); + virBufferAddLit(&buf, " # dri libs will trigger that, but t is not requited and DAC would deny it anyway\n"); + virBufferAddLit(&buf, " deny \"/var/lib/libvirt/.cache/\" w,\n"); + } if (ctl->newfile) if (vah_add_file(&buf, ctl->newfile, "rwk") != 0) -- 2.17.1
On Mon, 18 Feb 2019, Christian Ehrhardt wrote:
+ virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**.so\" mr,\n");
I'm sorry I think I wasn't clear on how to add in the .so files. I suggest: virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/*.so*\" mr,\n"); virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/*.so*\" mr,\n"); virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/*.so*\" mr,\n"); This is slightly futureproofed with the trailing '*'. On my system, the '**' wasn't needed, but if you observe systems where it is, feel free to keep it. The other parts of this patch looked fine. -- Jamie Strandboge | http://www.canonical.com
On Fri, Feb 22, 2019 at 2:42 PM Jamie Strandboge <jamie@canonical.com> wrote:
On Mon, 18 Feb 2019, Christian Ehrhardt wrote:
+ virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/**.so\" mr,\n"); + virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/**.so\" mr,\n");
I'm sorry I think I wasn't clear on how to add in the .so files. I suggest:
At least I didn't make it up - I asked on apparmor channels and this is what I got :-)
virBufferAddLit(&buf, " \"/usr/lib{,32,64}/dri/*.so*\" mr,\n"); virBufferAddLit(&buf, " \"/usr/lib/@{multiarch}/dri/*.so*\" mr,\n"); virBufferAddLit(&buf, " \"/usr/lib/fglrx/dri/*.so*\" mr,\n");
This is slightly futureproofed with the trailing '*'. On my system, the '**' wasn't needed, but if you observe systems where it is, feel free to keep it.
I checked through all of Debian/Ubuntu with apt-file and found no cases that really need the **. Thereby I'll take your suggestion and push it (after another round of safety builds) with your ack (as all else was already fine).
The other parts of this patch looked fine.
-- Jamie Strandboge | http://www.canonical.com
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
participants (2)
-
Christian Ehrhardt -
Jamie Strandboge