Re: Propose to distribute a user-only install script, not admin required

[Josh Marshall <joshua.r.marshall.1991@gmail.com>]

Another non-chroot option is `fakechroot`, which seems to get the same
effect without root.  It does make me wonder why `chroot` requires
privileged access at all.

As I'm slowly getting more familiar with guix, the more I think the
internal design ought to change.  I'm finding that how it works right
now is inelegant if you need to shift the application of guix a little
bit.  If you want a native guix experience vs secondary package
manager they have to be configured differently and daemon details seem
to need to leak to the client.  For users who need unprivileged access
to use guix, setup is more difficult when similar tools can work
without hassle.  Tracing back errors across the client and server
requires extra knowledge of implementation to understand what errors
actually mean, increasing the barrier to entry.

If guix changed such that it had the ability to work as a single
standalone binary, and optionally checked something with dbus or a
reserved unix socket to coordinate with an existing daemon, other
instances of guix running on the system, or launch a daemon on demand
then the number of use cases where guix would just work would
significantly increase.  Having all functionality in a single binary
would also make error handling and determination easier.  There are
ways to make the current approach accomplish all of these goals, but
it would be more complex and seems like it is ultimately trying to
approximate the restructuring I'm suggesting.


On Sat, May 16, 2020 at 10:05 PM Bengt Richter <bokr@bokr.com> wrote:
>
> Hi Josh, Tobias, et al,
>
> On +2020-05-16 17:47:39 +0200, Tobias Geerinckx-Rice wrote:
> > Josh,
> >
> > Josh Marshall 写道：
> > > One thing which I think could significantly aid adoption would be up
> > > either add an option or add a new installer script with guix
> > > configured to install and run purely out of the user's home directory
> > > without any special permissions.
> >
> > An old but classic place to start is [0] which explains some of the problems
> > & trade-offs, and illustrates an approach that may or may not still work
> > today.
> >
> > My subjective impression was that this used to be more of a big deal (i.e. a
> > few years ago) than it is now.  I don't know if it's less of a problem these
> > days, or people gave up on asking, or perhaps I'm not in the right channels
> > to hear the clamouring.
> >
> > Part of me thanks you for bringing this up again.  I'm interested to see
> > where it goes.
> >
> > Another part of me fears that ‘rootless Guix’ is just the perfect excuse for
> > misguided admins to give their users a pale and flavourless Guix experience.
> > It would rather taint the brand.
> >
> > Kind regards,
> >
> > T G-R
> >
> > [0]: https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org
>
> (I hadn't seen [0] above, but now I have :) So I will be wondering if
> proot is a good path to get where I want to go. I hope this thread
> will provide further input).
>
> I am happy to see this suggestion, as I have been experimenting with
> re-writing guix-install.sh to do something very related:
>
> (I am assuming a user who _can_ do useradd and groupadd, or get it done,
> but wants to run guix totally without needing root priviliges
> beyond that).
>
> It boils down to creating a new user-mode user called guixurootd
> to serve as "guix-root" daemon and manage running the builders
> with inter-user permission isolation but not involving root.
>
> I'm hoping some combination of group membership and permissions
> will enable safe multithread isolation without involving actual root
> privileges for guixurootd.
>
> My motivation was really not liking to run guix-install.sh as root.
> Big complex chains of actions that involve unnecessary global
> root privileges scare me, even if I can inspect the script.
>
> So my first thought was to split it into two: the part that can
> run fine without sudo to root (which is most of it) and the part that
> requires sudo to root, which is creating the daemon and builders, and
> writing to / and ~root, and something I forgot probably :).
>
> The latter requirement goes away when writing to / becomes
> writing to /home/guixurootd/ and /home/guixurootd/root
>
> I really would like the entire guix usage of "/" to become
> usage of "/home/guixurootd/" including /var /etc /root/.dotfiles
> /tmp and _everything_, so that the impact on a "foreign distro"
> is totally contained in the guixurootd $HOME file space plus
> the existence of the $HOME-less builders.
>
> I am in a design-churn phase for the moment, trying to
> factor everything into place ;-)
>
> Ideally installation could become something like
> --8<---------------cut here---------------start------------->8---
> 1. sudo sys_create_build_user # as defined in guix-install.sh
> 2. sudo useradd -U -G guixbuild                  \
>      -m -k $tmp_skeldir -s "$(which nologin)"    \
>      -c "Guix user-root daemon" --system         \
>      "guixurootd";
> 3. download and verify guixurootd-install.sh
> 4. sudo -u guixrootd guixurootd-install.sh
> --8<---------------cut here---------------end--------------->8---
>
> but wondering whether to live with /etc/skeldir (think not entirely)
> or what to put in $tmp_skeldir...
>
> Maybe even more ideally, the guixurootd daemon could populate itself
> by cloning the guix repo and automatically proceed according to
> https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
>
> I.e. sudo -u guixurootd 'cd;bin/init' automatically would do
> git clone https://git.savannah.gnu.org/git/guix.git
> (BTW, should a specific commit be specified by install docs,
> to avoid becoming invalid due to later commit breakage??)
> (BTW2 any-whatever-install.sh should be version controlled and signed too, IMO :)
>
> I'm thinking skeldir/bin/init would be a minimal kick-start script to run
> build stuff from the repo. Or maybe skeldir/.profile could do it without a skeldir/bin
> ... wip ;-)
>
> So anyway git would store the repo at /home/guixurootd/guix/ and then
> the init script would somehow execute a "build-from-git" sequence
> automatically, at the end of which all other users on the machine
> have to do is set up their ~/.guix-profile and ~/.bash_profile
> to tie in, maybe starting with the (now deprecated?) advice to
> use /usr/local/bin like
>
> # mkdir -p /usr/local/bin
> # cd /usr/local/bin
> # ln -s /home/guixurootd/var/guix/profiles/per-user/root/current-guix/bin/guix
> if /var really were moved there ... wip ;)
>
> Anticipating potholes and brick walls ...
>
> One thing I'd like to do is make this new guixurootd-install.sh
> stateful -- I'm thinking by logging passed and failed milestones
> to a source-able file like a bash_history with dates in comments
> so that re-tries don't waste my time (or internet budget).
> Lines like
> autoconf=1  # 2020-05-17 01:56:55 +0200
> with the file initialized from a template with all steps =0
> and including the template version and where to find it, with
> self-referential hash :)
>
> Still wip ;-)
>
> I'm wondering whether to make guixurootd support login or not.
> Or just rely on sudo -u
> (Maybe some special setuid
> helper will have to be created for privilege lowering?
> I haven't got that far yet.
>
> Maybe it could be done without any changing of privileges at all,
> with the guixurootd daemon and builderXX processes cooperating
> by message passing using that new extent-swapping kernel api
> that atomically (IIUC) swaps page-sequemces between files of
> cooperating users. That should be fast, since it's just like mmap
> table manipulation IIUC.
>
> So there's my 2 cents worth of bike shed paint :)
> Well, a little more, I hope. I'll be poking at it, but now
> will hope for ideas and prior art revelations here ;-)
>
> BTW, might encapsulating all of guix in the guixurootd $HOME file space
> serendipitously work with that systemd home encapsulator/migration-
> facilitator that I don't even know the right name of, possibly?
>
> --
> Regards,
> Bengt Richter