Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

Ludovic Courtès schreef op ma 04-10-2021 om 16:32 [+0200]:
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
> > > Maxime Devos <maximedevos@telenet.be> skribis:
> > > 
> > > > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> > > > > Hi,
> > > > > 
> > > > > Joshua Branson <jbranso@dismail.de> skribis:
> > > > > 
> > > > > > Apologies if I'm speaking for something I know very little
> > > > > > about...Wouldn't it be nice if guix home services would accept a 
> > > > > > user
> > > > > > and a group field?  For the syncthing service, perhaps the user 
> > > > > > wants to
> > > > > > limit Syncthing's runtime permissions.  So instead of running as the
> > > > > > user, the user would run synthing as a different user with less 
> > > > > > permissions?
> > > > > 
> > > > > That’s not possible unless the calling user is root, since you’d need
> > > > > the ability to switch users somehow.
> > > > 
> > > > On Debian, a user has a list of ‘subordinate user IDs’ which can be 
> > > > switched
> > > > to without root: 
> > > > <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>;;.
> > > > 
> > > > Maybe "guix home" could use that mechanism, and this mechanism could be 
> > > > implemented
> > > > on Guix System as well?
> > > 
> > > Yes but that requires unprivileged user namespaces, which may or may not
> > > be supported—e.g., likely unsupported when using Home on a foreign
> > > distro.
> > 
> > I don't recall newuidmap requiring unprivileged user namespaces -- it's a 
> > setuid binary.
> 
> Ah right.  But we’re not call do (system* "/usr/sbin/newuidmap") in
> service code, so that’s still a problem, no?

It might be possible to modify 'make-forkexec-constructor/container' to call
(exec-command (cons* newuidmap ARGUMENTS-TO-NEWUIDMAP command) ...),
where newuidmap is (search-input-file "newuidmap" '("/run/setuid-programs" 
"/usr/sbin" "/sbin")).
That path should work on Guix System and many foreign distro, presuming the 
distro
is configured to make "newuidmap" setuid.

There might be complications w.r.t. bind mounts though (presumably setuid 
binaries
don't like being called if the (unprivileged) parent process has created some 
bind mounts?),
so the bind mounting code might need to be performed as a child process of 
newuidmap,
but in principle, everything should be implemented I think.

I'm not volunteering to write this code though.

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part