It's not possible to call fusermount

[Leo Arias]

IPFS has a feature to mount the distributed file system. It call's fusermount, and that's blocked by seccomp:

Time: Mar 15 11:09:39
Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=18104 comm="fusermount" exe="/snap/ipfs/x1/bin/fusermount" sig=31 arch=c000003e 122(setfsuid) compat=0 ip=0x7f806d8a38f7 code=0x0
Syscall: setfsuid

= Seccomp =
Time: Mar 15 11:09:58
Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=18109 comm="fusermount" exe="/snap/ipfs/x1/bin/fusermount" sig=31 arch=c000003e 122(setfsuid) compat=0 ip=0x7f5319ead8f7 code=0x0
Syscall: setfsuid

https://ipfs.io/docs/commands/#ipfs-mount

[Jamie Strandboge (jdstrand)]

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

[Leo Arias (elopio)]

Thanks Jamie!

[Jamie Strandboge (jdstrand)]

@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?

[Leo Arias (elopio)]

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 / ?

[Jamie Strandboge (jdstrand)]

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?

[Jamie Strandboge (jdstrand)]

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

[Jamie Strandboge (jdstrand)]

"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.

[Zygmunt Krynicki (zyga)]

@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.