It's not possible to call fusermount

This should simply be a matter of adding setfsuid to the fuse-support interface.

Thanks Jamie!

@Leo, looking at this more, fusermount will do:

  static void drop_privs(void)
  {
          if (getuid() != 0) {
                  oldfsuid = setfsuid(getuid());
                  oldfsgid = setfsgid(getgid());
          }
  }
  static void restore_privs(void)
  {
          if (getuid() != 0) {
                  setfsuid(oldfsuid);
                  setfsgid(oldfsgid);
          }
  }

therefore, setfsuid/setfsgid will only be called if running fusermount as non-root. The fuse-support interface is currently not written to support unprivileged fuse mounts. Per https://github.com/snapcore/snapd/wiki/Interfaces#fuse-support:

"
fuse-support
  Can mount fuse filesystems (as root only).
  Auto-Connect: no
"

One of the reasons why fusermount is not supported at this time is because setfsuid allows changing the fsuid that is used with DAC checks and AppArmor owner match. Allowing the use of this system call would grant unexpected elevated privileges to the snap and allow the snap to bypass intended access restrictions (ie, avoid the DAC and 'owner' AppArmor checks). I'm disinclined to add setfsgid, setfsgid32, setfsuid and setfsuid32 (even with argument filtering) to the fuse-support interface because of this.

*Perhaps* a new 'setfsuid' interface could be provided, but snap daemons that plugs fuse-support should work fine without these syscalls as should snap commands that plugs fuse-support that run under sudo.

Does running as a daemon or under sudo not suffice?

Thanks for the info Jaime. I think IPFS is not ready to be run as root because it has no authentication per user in the system, but I will ask. Does it change something if the mount point is in $SNAP_USER_DATA instead of / ?

This seems like it is what I described in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5. Can you check? If it is, might want to comment in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1663029 for ways on making the alsa interface easier to use.

Zygmunt, you also mentioned that you would look into this-- what was the outcome?

I'm sorry, I commented in the wrong bug. Please ignore comment #5.

"Does it change something if the mount point is in $SNAP_USER_DATA instead of / ?"

It adds another variable to the mix but doesn't change the privilege escalation, no.

Based on the comments from Leo, marking as Confirmed but unassigning myself for now.

@jdstrand - no, not yet, sorry. I'm crawling from under my pile now so I can explore it in the next cycle but no promises on if I can fix it.