mount_service: possible implementation changes

mount_service: possible implementation changes

[Skye Soss]

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.

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.

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

Re: mount_service: possible implementation changes

[Darrick J. Wong]

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

Re: mount_service: possible implementation changes

[Skye Soss]

 > On Mon, Jul 06, 2026 at 05:26:18PM -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. 
 >  
 > 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.

A privileged service can enter the mount namespace of its peer by obtaining
the pid via SO_PEERPIDFD, and passing /proc/$pid/ns/mnt to setns().

SO_PEERPIDFD is Linux kernel 6.5+, but the commit message alludes to a
portable alternative if we need to support older kernels
(ba47545c756b55f4b114c45fea7d52dd1577e181).

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

I'm not sure it does because the `fuservicemount` binary would no longer be
security-sensitive. Ie. it would remove all of the `drop_privs`/`restore_privs`
calls that litter the mount_service file, as there will now only be one
privilege transfer boundary.

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