Re: mount_service: possible implementation changes

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