Comment 1 for bug 1804869

Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: Daemons do not have an /run/user/* dir created on Ubuntu Classic

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 waylandPermanentSlotAppArmor policy was not applied. Looking in interfaces/builtin/wayland.go, this is clearly because of:

func (iface *waylandInterface) AppArmorPermanentSlot(spec *apparmor.Specification, slot *snap.SlotInfo) error {
        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
Feb 19 15:38:25 sec-xenial-amd64 mir-kiosk.mir-kiosk[5647]: mkdir: cannot create directory '/run/user/0': Permission denied

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.