hw-assign allows assigning to multiple snaps, but only one snap has access

[Jamie Strandboge]

Test case:

First hw-assign /dev/kmsg to a snap:
$ hello-world.usehw
Hello hw-assign world!
This example demonstrates the app confinement for assigned hardware

No hardware is assigned for this device. Try adding /dev/kmsg with:
  $ sudo snappy hw-assign hello-world.canonical /dev/kmsg

$ sudo snappy hw-assign hello-world.canonical /dev/kmsg
'hello-world.canonical' is now allowed to access '/dev/kmsg'

$ hello-world.usehw
Hello hw-assign world!
This example demonstrates the app confinement for assigned hardware

Good, '/sys/devices/virtual/mem/kmsg' is assigned to us.
Now try to read a line from /dev/kmsg:
6,0,0,-;Initializing cgroup subsys cpuset

It worked!

Now verify the tag in udev:
$ cat /run/udev/data/c1:11
I:19300397
E:SNAPPY_APP=hello-world.canonical
G:snappy-assign

Now hw-assign /dev/kmsg to a different snap:
$ sudo snappy hw-assign webdm /dev/kmsg
'webdm' is now allowed to access '/dev/kmsg'

Now verify the tag in udev:
$ cat /run/udev/data/c1:11
I:19300397
E:SNAPPY_APP=webdm
G:snappy-assign

Notice that the 'SNAPPY_APP' property does not contain hello-world.canonical. If we run hello-world.usehw we can see it is no longer in its devices cgroup:
$ hello-world.usehw
Hello hw-assign world!
This example demonstrates the app confinement for assigned hardware

No hardware is assigned for this device. Try adding /dev/kmsg with:
  $ sudo snappy hw-assign hello-world.canonical /dev/kmsg

And we can see in /etc/udev/rules.d that both are assigned to the device:
$ cat /etc/udev/rules.d/70-snappy_hwassign_*

KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="hello-world.canonical"

KERNEL=="kmsg", TAG:="snappy-assign", ENV{SNAPPY_APP}:="webdm"

The udev implementation is only allowing one app per device while hw-assign is allowing multiple apps to the same hardware. I believe the udev portion is implementing the intended design so snappy needs to error if the specified device is already assigned. Note: when adjusting snappy hw-assign you may want to only do this check on /dev and not /sys/devices and /sys/class since people tend to use globs with those /sys accesses and because those /sys accesses don't update the udev tags. The gadget/OEM assign rules will also suffer from this bug and the checks in snappy will have to be more thorough to avoid this bug (imagine one rule uses 'with-attrs' and another 'with-props' but they both map to the same device-- only one snap will get the udev tag).

[Michael Vogt (mvo)]

Is this something we need to fix in the interfaces snappy world of ubuntu-core 16?

[Launchpad Janitor (janitor)]

[Expired for Snappy because there has been no activity for 60 days.]