Namespace awareness of /run/mount/utab (and libmount)

snapd
,
1

During the review of the new cifs-mount-control we noticed that the path /run/mount/utab needs to be written to. This is a problem because we share that file with the initial mount namespace. The file is used by libmount to record some userspace-only facts about existing mounts.

What is apparent if you look at that file is that it is not namespace aware. I had a quick look at what happens in LXC/LXD and you can see that a vanilla tmpfs is mounted over all of /run so that the file is not clashing there.

In our case the file is even more tricky as (in an ideal world) it would show all the mounted things that apply from the initial namespace as well as the things that are mounted on the inside of the snap. Obviously the host is free to mutate the file (as a result of mount operations) and such updates should be reflected on the inside.

One possible (low-tech) solution would involve snap-confine making a copy of that file on snap startup, hiding the original and snapd observing the original file (e.g. inotify of fanotify) and on each transaction on that file, lock it in a way compatible with libmount, take a snapshot, compute the changes and apply them to the inside of each mount namespace.

Iā€™m investigating libmount in more detail to see how it is being used and what would happen if we have an imperfect solution.

1 Like
2

It seems functionality is not touched by this (I was able to mount and umount the cifs share without problem after I removed the apparmor permission for /run/mount/utab). It is listed in the security violations though:

= AppArmor =
Time: Jun 18 13:27:33
Log: apparmor="DENIED" operation="open" profile="snap.smb-copier.smb-copier" name="/run/mount/utab" pid=4586 comm="umount" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0
File: /run/mount/utab (write)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use run/shm/snap.$SNAP_NAME.*
3

Hopefully itā€™s only used for storing x-* options as mentioned in mount(8) manpage:

       x-*    The  same  as  X-*  options,  but stored permanently in the user
              space. It means the options are also  available  for  umount  or
              another  operations.   Note  that maintain mount options in user
              space is tricky, because it's necessary use libmount based tools
              and there is no guarantee that the options will be always availā€
              able (for example after a move mount operation  or  in  unshared
              namespace).

Unsurprisingly comes with a warning about mount namespaces. So maybe itā€™s ok to just bind mount an empty file over that path?

1 Like
4

I have reported this issue upstream: https://github.com/karelzak/util-linux/issues/649

5

So perhaps one of the most simple solutions would be to simply create a private utab file for each snap?

1 Like