Feature request: parameterized /var/guix/profiles/per-user

  • Open
  • quality assurance status badge
Details
2 participants
  • Dimitri DELABROYE
  • Ludovic Courtès
Owner
unassigned
Submitted by
Dimitri DELABROYE
Severity
wishlist
D
D
Dimitri DELABROYE wrote on 19 Jan 2021 14:34
(address . bug-guix@gnu.org)(address . support-staff@lists.grid5000.fr)
a004eb62-a2c3-b9c9-be94-d88cfc68cf1b@inria.fr
Hi,

We have installed guix following this cluster documentation
Grid'5000 which is a testbed.

In order to be more secure we did not want to export /var/guix with RW
rights, we cannot trust root on the nodes. So for the user profile to
work we did the following:
    - mount the user's home on the guix server
    - instead of letting guix create the user's profile on
/var/guix/profiles/per-user we created symlink: ln -s /home/USER/.guix
/var/guix/profiles/per-user/USER
This way we can export /var/guix with RO rights and users can't see each
others profiles.

Another way would be to have a parameter to configure the
/var/guix/profiles/per-user directory so the symlink mecanism would not
be needed. For example guix could directly write in the user directory
in /home/USER/.guix.

Best regards,
Dimitri

Grid'5000 Techteam
L
L
Ludovic Courtès wrote on 21 Jan 2021 15:34
(name . Dimitri DELABROYE)(address . dimitri.delabroye@inria.fr)
871ree9x5z.fsf@gnu.org
Hi Dimitri,

Dimitri DELABROYE <dimitri.delabroye@inria.fr> skribis:

Toggle quote (3 lines)
> In order to be more secure we did not want to export /var/guix with RW
> rights, we cannot trust root on the nodes.

Just so those unfamiliar with Grid’5000 understand: what’s special here
is that users can spawn new nodes where they are root, but this root
user is not trusted as an admin of the cluster as a whole.

Thus, if /var/guix as we know it were NFS-exported read/write, anyone
could fiddle with all of /var/guix/profiles/per-user. That’s the reason
why Dimitri & co. came up with the idea of storing per-user profiles in
each user’s home directory.

Why home directories? Because there’s already machinery on G5K that
arranges so that a node can NFS-mount nothing but the home directory of
the user who reserved the node.

Why not treat /var/guix/profiles/per-user/USER NFS shares in the same
way as home directories, then? That’s an option, but that’d mean extra
work for G5K, AIUI.

Toggle quote (9 lines)
> So for the user profile to
> work we did the following:
>     - mount the user's home on the guix server
>     - instead of letting guix create the user's profile on
> /var/guix/profiles/per-user we created symlink: ln -s /home/USER/.guix
> /var/guix/profiles/per-user/USER
> This way we can export /var/guix with RO rights and users can't see
> each others profiles.

The problem is that ‘gc-roots’ in (guix store roots) won’t traverse
those /per-user/USER symlinks. Instead, it assumes they are symlinks to
indirect roots.

Toggle quote (5 lines)
> Another way would be to have a parameter to configure the
> /var/guix/profiles/per-user directory so the symlink mecanism would
> not be needed. For example guix could directly write in the user
> directory in /home/USER/.guix.

In fact, it’s possible to use profiles other than the default profile,
and those profiles can be anywhere on the file system. For instance, if
you do:

guix install -p ~/.guix/my-profile emacs

the thing is installed in ~/.guix/my-profile; that profile does not show
up in /var/guix/profiles, but it is seen as a GC root by the daemon, via
/var/guix/gcroots/auto.

Longer-term, we could imagine having a “private profile” option, where
the default profile is managed this way instead of being visible in
/var/guix/profiles/per-user. But obviously that needs more thought and
it’s not an option to solve your immediate problem.


As it stands, the simplest option I think would be handle NFS exports of
/var/guix/profiles/per-user/USER just like exports of /home/USER.

Thoughts?

Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 45980@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 45980
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch