Re: mount_service: possible implementation changes

["Darrick J. Wong" <djwong@kernel.org>]

On Sun, Aug 09, 2026 at 11:23:36AM -0500, Skye Soss wrote:
>  > > > 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.

Er, why is that?  Does AppArmor not enforce the same rules between an
unprivileged process trying a direct mount() vs. a privileged process
that has entered another process' mount namespace to call mount()?

Can you setns more namespaces (e.g. enter the user namespace as well and
then setuid to the socket client process' credentials?)

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

Huh.  So the defused daemon forks a child which adds its own seccomp
filter, and only then does it enter the socket client's mount namespace
to attach the mount?

Clever. :)

--D