incomplete 'opengl' interface

Bug #1605768 reported by Cemil Azizoglu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
High
Jamie Strandboge

Bug Description

I tried running some of the snaps that use the 'opengl' interface on my Xenial machine with Intel Mesa drivers.

I received the following apparmor denials
  /run/udev/data/c226:128 r,
  /run/udev/data/c226:129 r,

and the following seccomp failures
  memfd_create

Once these were added to the apparmor and seccomp profiles, the snaps work.

Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

Note that for opengl client rendering the graphics driver uses the so called 'render' nodes in '/dev/dri'. On my system, this directory contains :

$ll /dev/dri/
total 0
drwxr-xr-x 2 root root 160 Jul 22 11:47 ./
drwxr-xr-x 20 root root 4700 Jul 22 11:47 ../
crw-rw----+ 1 root video 226, 0 Jul 22 11:47 card0
crw-rw----+ 1 root video 226, 1 Jul 22 11:47 card1
crw-rw---- 1 root video 226, 64 Jul 22 11:47 controlD64
crw-rw---- 1 root video 226, 65 Jul 22 11:47 controlD65
crw-rw----+ 1 root video 226, 128 Jul 22 11:47 renderD128
crw-rw----+ 1 root video 226, 129 Jul 22 11:47 renderD129

The driver uses udev to discover these nodes and needs access to the following files

  /run/udev/data/c226:128
  /run/udev/data/c226:129

in order to obtain the PCI information contained therein.

Therefore, composing the list of apparmor entries for the 'opengl' interface should query these render nodes. It can then form the paths by using the <major> and <minor> device numbers. I.e.

/run/udev/data/c<major>:<minor>

tags: added: snapd-interface
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thank you for reporting a bug. The /run/udev/data is usually non-fatal (but that doesn't mean we won't fix it). Can you:

1. add memfd_create to /var/lib/snapd/seccomp/profiles/snap.your.snap

2. try restarting your application and report back if it works or if you need more syscalls

3. add this to /var/lib/snapd/apparmor/profiles/snap.your.snap:
/run/udev/data/c226:12[89] r,

4. load the updated profile in the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.snap

5. try restarting your application and report back if it works or if you need more rules

Thanks!

Changed in snapd (Ubuntu):
status: New → Incomplete
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → High
Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

As I mentioned in the description, these do make my snap work.

Changed in snapd (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I was more curious if just memfd_create allowed it to work, but it doesn't matter now.

Changed in snapd (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

You're right, just memfd_create makes it work... AppArmor denials still come happen but the app runs nevertheless.

affects: snapd (Ubuntu) → snappy
Changed in snappy:
status: In Progress → Fix Committed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This was fixed in 2.12 and is available in xenial-updates.

Changed in snappy:
status: Fix Committed → Fix Released
Zygmunt Krynicki (zyga)
Changed in snappy:
milestone: none → 2.12
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.