# Allow write access to create /run/user/* to create XDG_RUNTIME_DIR (until lp:1738197 is fixed)
/run/user/[0-9]*/ w,
This was committed to the wayland interface a long time ago (December 2017). I took a like at this and discovered that the above rule is not in place after installing mir-kiosk on xenial:
What needs to happen is the wayland interface needs to be converted to not do this. I can't see how this would've ever worked in the past unless something created the directory ahead of time (a previous devmode snap maybe)? Looking in the logs after a stop and start I see the denial:
When I create the directory after a stop, I see this:
Feb 19 15:40:19 sec-xenial-amd64 audit[5794]: AVC apparmor="DENIED" operation="mknod" profile="snap.mir-kiosk.mir-kiosk" name="/run/user/0/wayland-0.lock" pid=5794 comm="miral-kiosk" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
This, again, is because the AppArmorPermanentSlot policy is not added to the profile (incidentally, there is a rule for /etc/drirc in the ConnectedPlug, but the PermanentSlot seems to need it too).
The path forward is a PR that removes the 'if !release.OnClassic {' conditionals, verify everything works and add any new policy (perhaps conditionally on if the release is classic). There is analogous precedent for this in the network-manager interface.
I apologize for only just looking at this now.
The wayland interface has:
# Allow write access to create /run/user/* to create XDG_RUNTIME_DIR (until lp:1738197 is fixed)
/run/user/[0-9]*/ w,
This was committed to the wayland interface a long time ago (December 2017). I took a like at this and discovered that the above rule is not in place after installing mir-kiosk on xenial:
$ ls -l /run/user
total 0
drwx------ 7 lightdm lightdm 140 Feb 19 15:07 108
$ sudo snap install core
$ sudo snap install mir-kiosk
$ snap interfaces mir-kiosk
Slot Plug
:opengl mir-kiosk
mir-kiosk:mir -
mir-kiosk:wayland -
$ grep '/run/user/ \[0-9\] \*/ w,' /var/lib/ snapd/apparmor/ profiles/ snap.mir- kiosk.mir- kiosk
$
The policy in waylandPermanen tSlotAppArmor policy was not applied. Looking in interfaces/ builtin/ wayland. go, this is clearly because of:
func (iface *waylandInterface) AppArmorPermane ntSlot( spec *apparmor. Specification, slot *snap.SlotInfo) error {
spec. AddSnippet( waylandPermanen tSlotAppArmor)
if !release.OnClassic {
}
return nil
}
What needs to happen is the wayland interface needs to be converted to not do this. I can't see how this would've ever worked in the past unless something created the directory ahead of time (a previous devmode snap maybe)? Looking in the logs after a stop and start I see the denial:
Feb 19 15:38:25 sec-xenial-amd64 audit[5754]: AVC apparmor="DENIED" operation="mkdir" profile= "snap.mir- kiosk.mir- kiosk" name="/run/user/0/" pid=5754 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 mir-kiosk[ 5647]: mkdir: cannot create directory '/run/user/0': Permission denied
Feb 19 15:38:25 sec-xenial-amd64 mir-kiosk.
When I create the directory after a stop, I see this: "snap.mir- kiosk.mir- kiosk" name="/ run/user/ 0/wayland- 0.lock" pid=5794 comm="miral-kiosk" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Feb 19 15:40:19 sec-xenial-amd64 audit[5794]: AVC apparmor="DENIED" operation="mknod" profile=
This, again, is because the AppArmorPermane ntSlot policy is not added to the profile (incidentally, there is a rule for /etc/drirc in the ConnectedPlug, but the PermanentSlot seems to need it too).
The path forward is a PR that removes the 'if !release.OnClassic {' conditionals, verify everything works and add any new policy (perhaps conditionally on if the release is classic). There is analogous precedent for this in the network-manager interface.