The mount-observe interface

The mount-observe interface enables a snap to read mount table and quota information. The interface grants access to files such as:

  • /proc/self/mountinfo, /proc/self/mounts see currently mounted filesystems
  • /sys/devices/*/block/* block device attributes, often accessed through corresponding /sys/class/block/* symbolic links
  • /etc/fstab, /run/mount/utab, enabling use of the mount program

As well as access to mount specific syscalls, such as:

  • listmount(2), statmount(2)
  • quotactl(2), with commands for observing the limits such as X_GETINFO, X_GETQUOTA, X_GETSTAT

This interface is restricted because it gives privileged read access to mount arguments and should only be used with trusted apps.

Auto-connect: no

ⓘ This is a snap interface. See Interface management and Supported interfaces for further details on how interfaces are used.

I would like to know what does this interface’s connection makes any noticeable difference to the Gtk file picker, which seems to require this interface.

Because of underlying libraries, the different file pickers may try to access files provided by this interface, but the accesses are usually just noise. In fact, depending on the file picker, the situation can be made worse since it might make a wrong decision based on the snap’s mount namespace (which I’ve observed).

1 Like

Am I right in thinking that the specific issue here is things like e.g. mount.cifs’s password option, and there’s lots of machines where “privileged read access to mount arguments” wouldn’t be problematic at all?

Yes. Do note that often times mount-observe is not required at all and the denials are just noise in the logs.