Re: mount_service: possible implementation changes

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

On Mon, Jul 06, 2026 at 05:26:18PM -0500, Skye Soss wrote:
> Right now the new mount_service protocol works by first gaining root
> capabilities via fuservicemount being setuid, then communicating with
> a socket-activated systemd service to run the actual filesystem
> implementation in a sandboxed systemd unit.
> 
> I think there could be an improvement to the design by instead moving
> the privileged parts into a systemd socket activation unit, and having
> that privileged service spawn the containerized systemd unit as a
> child transient unit, or via socket activation with a root-only socket
> file.
> 
> 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.

How do you get the socket-activated part of fuservicemount to call
move_mount() (mounting) and openat() (resource acquisition) in the same
mount namespace as the directly-invoked part of fuservicemount?  A
socket service has no idea what namespace(s) are in use by the client;
its entire relationship with the client is limited to whatever is shared
through the socket.

> The advantage of this approach over the current design is
> compatibility with containers with the no_new_privileges security
> feature enabled. That disables privilege-elevation through execve (ie.
> setuid and setcaps binaries), but the use of systemd socket activation
> would still work.

Yes, though this adds more moving parts to the machinery.

> The other advantage is limiting the access of the filesystem sandbox
> startup to the privileged service, which can prevent issues arising
> from parsing bugs (not privilege escalation, but potentially DOS
> issues by escaping the systemd resource-control group).

I am, of course, curious to read any patches you have implementing this.

--D