Per snap mounting lacks of boot partition on UC18

Hello,

I’m trying to use uefi-fw-tools snap which originally worked on UC16 to verify fwupd behavior on UC18, but unfortunately I got a unknown failure when fwupdmgr did bios update. After some investigations, I find out the differences compared to UC16:

  1. for UC16, /boot/efi and /boot/grub are mounted on host and also per snap namespace:
$ sudo snap run --shell uefi-fw-tools.fwupdmgr
root@localhost:/var/lib/snapd# mount | grep boot
/dev/sda2 on /var/lib/snapd/hostfs/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda2 on /var/lib/snapd/hostfs/boot/grub type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda2 on /boot/grub type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
  1. for UC18, /boot/efi and /boot/grub are mounted on host but not per snap namespace:
$ sudo snap run --shell  uefi-fw-tools.fwupdmgr
root@localhost:/var/lib/snapd/hostfs# mount | grep boot
/dev/sda2 on /var/lib/snapd/hostfs/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda2 on /var/lib/snapd/hostfs/boot/grub type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

We can see /boot/efi and /boot/grub (bind mount on host) both on host, but we can’t see them in the snap namespace, although they indeed exist under the path /var/lib/snapd/hostfs.

Due to above case, fwupd can’t put firmware file into /boot/efi/EFI/ubuntu/fw because there is no such path in the snap execution environment, so I get stuck here.

Then, I checkout snapd git tree and there are several testing about mount-ns to verify what’s expectation for distro/basis. I suspect there exists the change to explain above phenomenon but I don’t dig into yet, so I’d like to understand my observation has any defect. Furthermore, is it possible to workaround this by adding /boot/efi into mount-support.c like

{"/boot/efi",.is_optional = true},

Any feedback would be appreciated, thanks.

The snap sandbox is constructed differently on Ubuntu Core 16 systems compared to others when running snaps that use core as the base: rather than running the code you found with the list of paths to bind mount into a fresh mount namespace, it takes the primary mount namespace and unshares it, on the basis that it represents what the snap would run against anyway. The details are described here:

When you run on a UC18 (or UC20 in future), this mode doesn’t happen. Further more, updating uefi-fw-tools to use a base matching the system it is running on wouldn’t help either, since the newer pivot root code is always run.

Always binding mounting /boot into the snap mount namespace would probably solve the problem, but given that this is specific to fwupd, I wonder if it would make sense to only do it for snaps that have a fwupd slot? We do something similar for exposing fonts to snaps plugging the desktop interface. This way the make sure we don’t inadvertently expose the information to other snaps (although AppArmor should take care of that if everything is behaving correctly).

1 Like

What @jamesh said is correct. I agree and I think we should switch to having these directories get mounted into the snap’s mount namespace only when the fwupd interface is connected. @jdstrand @zyga-snapd thoughts on making the fwupd interface mount these directories into the snap’s mount namespace?

Note that this rule would likely be for the slot side of the interface (it’s fwupd that sets up the UEFI capsule update rather than the the fwupd client). So it won’t be dependent on interface connection.

1 Like

Yeah. Seems reasonable.

Sorry for late response, and I’ve sent PR: https://github.com/snapcore/snapd/pull/8667

Thanks @zyga-snapd for quickly reviewing it.:slight_smile:

2 Likes