Failure to install maas snap in a container on a host using nvidia drivers

[Björn Tillenius]

Using snapd 2.29.4.2 in an up to date lxd container, installing the maas snap fails:

maas-devel:~> sudo snap install --devmode maas
2018-01-05T11:08:14Z INFO Waiting for restart...
error: cannot perform the following tasks:
- Mount snap "maas" (1349) ([stop snap-maas-1349.mount] failed with exit status 1: Job for snap-maas-1349.mount failed.
See "systemctl status snap-maas-1349.mount" and "journalctl -xe" for details.
)
- Run configure hook of "maas" snap if present (run hook "configure": cannot remount /tmp/snap.rootfs_V8aG2u/var/lib/snapd/lib/vulkan as read-only: Permission denied)

I've tried this both in xenial and bionic containers, and it fails the same way. Both containers were running on a xenial host.

[Björn Tillenius (bjornt)]

This seem to be related to my local setup. The above was using my desktop. When I tried the same on my laptop I was able to install maas. The setup of the laptop and desktop is similar, though.

[Björn Tillenius (bjornt)]

Looking more, there are some DENIALS in the host syslog:

Jan 9 12:16:36 lilium kernel: [62080.662451] audit: type=1400 audit(1515496596.906:295): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-maas-devel_</var/lib/lxd>" name="/tmp/snap.rootfs_99J0kb/var/lib/snapd/lib/vulkan/" pid=4067 comm="snap-confine" flags="ro, remount"
Jan 9 12:16:36 lilium kernel: [62080.687137] audit: type=1400 audit(1515496596.930:296): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-maas-devel_</var/lib/lxd>" name="/tmp/snap.rootfs_pZfQ0e/var/lib/snapd/lib/vulkan/" pid=4058 comm="snap-confine" flags="ro, remount"

I'm guessing this has to do with the nvidia drivers. I have nvidia-384 installed, and I remember having similar problems in the past.

[Zygmunt Krynicki (zyga)]

This appears to be fixed in master already, with the following code in snap-confine.apparmor.in

    # Vulkan support
    /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/* w,
    mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
    mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,

The reporter is testing the edge channel of the core snap now.

[Zygmunt Krynicki (zyga)]

The edge channel doesn't work. It seems the failing part is actually "flags" so (presumably) "ro, remount". We are investigating if this is a bug in the parser/kernel. We never used remount flag before.

[Björn Tillenius (bjornt)]

I'm still seeing this issue. But I found out that I can work around this issue by setting the container config security.nesting to true.

[Zygmunt Krynicki (zyga)]

If you were running a privileged container before then this is not supported. Snapd doesn't operate (but does not detect the presence of) a privileged container.

I'm marking this bug as incomplete. If this was a privileged container I think this should be closed as WONTFIX simply because there is nothing we could do about it. If there is a way to reproduce this without a privileged container it may be a valid issue to analyze.

[Launchpad Janitor (janitor)]

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