Fuse-support: DENIED failed type match

Hello all,

I have a snap [0] that makes use of the fuse-support interface.

However, it appears the AppArmor rules the interface implements does not fit the way the application is attempting to use fuse.

= AppArmor =
Time: Jun 06 03:41:38
Log: apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="snap.octavia-diskimage-retrofit.octavia-diskimage-retrofit" name="/var/snap/octavia-diskimage-retrofit/common/tmp/dib.pcyXwh/extra-data.d/" pid=30314 comm="virt-dib" fstype="fuse" srcname="/dev/fuse" flags="rw, nosuid, nodev"

I have connected the fuse-support plug, I am attempting to mount something in $SNAP_COMMON, and I am running the application as root as the interface documentation [1] states is required.

Any ideas?

0: https://github.com/openstack-charmers/octavia-diskimage-retrofit
1: https://docs.snapcraft.io/fuse-support-interface

The apparmor policy has:

mount fstype=fuse.* options=(rw,nosuid,nodev) ** -> /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/common/{,**/},

It looks like octavia is setting the fstype as “fuse” rather than the expected “fuse.something”. If you adjust /var/lib/snapd/apparmor/profiles/snap.octavia-diskimage-retrofit.octavia-diskimage-retrofit to have:

mount fstype=fuse* options=(rw,nosuid,nodev) ** -> /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/common/{,**/},

and then you compile/load this into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.octavia-diskimage-retrofit.octavia-diskimage-retrofit, does it work for you?

Either way, can you strace/code inspect and see how the mount is being setup?

With the amended AppArmor profile the mount is successful.

I did suspect the fstype, but was not entirely sure how the .* was interpreted by the AppArmor parser or what significance it would have to loosen the profile to include just fuse as fstype. Was not aware of those tricks for quick iteration on the profile either, so thank you for pointing me at that.

Here is a strace of a failed run: https://pastebin.ubuntu.com/p/7gkJw9Jz4r/
and here is a strace of a successful run: https://pastebin.ubuntu.com/p/BMtqW7XWq3/

Would you think we should update the AppArmor profile or would it be pertinent of libguestfs to use a named fstype?

I guess what may be different here from other fuse applications out there is that the libguestfs library and tools provide both the fuse driver and the applications consuming it.

A side note: The application does struggle when attempting to run fusermount to unmount just after this, and on the surface the application appears to be doing something strange. I will treat that as a separate issue and investigate some more.

The “strangeness” mentioned in the previous post comes from the steps fusermount takes to make sure it is not doing something it should not do: https://github.com/libfuse/libfuse/blob/63c11456d48b156b33b8b16cd47759c0d406f5b9/util/fusermount.c#L212

I understand that supporting that in the interface might be a bit more work than just updating the profile, so I’ll try to work around the need for unmounting for now.

Do tell me what you think about updating the fstype in the profile though, I’d be happy to propose a patch if it will be welcomed.

I think so. It is tidier for users irrespective of snaps.

Right, fuse-support only supports “running” a FUSE filesystem as root and not fusermount or unmounting. For these use cases, a ‘fuse-control’ interface would need to be created, likely with an installation constraint.