Re: mount_service: possible implementation changes

 > > > Ie. The fuservicemount binary would be a non-setuid binary, and simply
 > > > communicate with a socket in /run that is backed by a privileged
 > > > socket-activated service. Upon activation, the service would use the
 > > > peer credentials to enforce limits such as `mount_max`, and configure
 > > > `/dev/fuse`. Finally, it would spawn the sandboxed systemd unit to run
 > > > the filesystem, using `--scope` to transfer the file descriptors to
 > > > the new process, or using socket activation with a socket file that
 > > > only root can read and write to. 

 >  > I am, of course, curious to read any patches you have implementing this. 
 >  
 > Thanks for the interest! I'll try to write something up next week. 

I've been working on a proof-of-concept on-and-off for the past month, which you can
find at https://github.com/Skyb0rg007/defused.
I'd recommend just looking at the README and doc/protocol.md for details.

From my attempt at this redesign, I now think that this "client-server" approach is
probably *not* a good idea to merge into libfuse, and that its best to keep as a
separate project.
This is primarily because there aren't good ways to implement the filesystem access
check that a setuid program has access to: installing defused allows programs
to mount over directories that an AppArmor rule would have otherwise disallowed.

Another is security: the system service calls `setns()` on the client's mount namespace
with root privileges, which can very easily become a security issue if libc lazily
loads any shared libraries. I solve this by installing an extremely strict seccomp
filter, but this is not something libfuse should have to worry about.