unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: guix-devel@gnu.org
Subject: Re: Propose to distribute a user-only install script, not admin required
Date: Sun, 17 May 2020 04:05:35 +0200	[thread overview]
Message-ID: <20200517020535.GA3652@LionPure> (raw)
In-Reply-To: <87imgvop9g.fsf@nckx>

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


  reply	other threads:[~2020-05-17  2:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 15:25 Propose to distribute a user-only install script, not admin required Josh Marshall
2020-05-16 15:47 ` Tobias Geerinckx-Rice
2020-05-17  2:05   ` Bengt Richter [this message]
2020-05-24 19:19     ` Josh Marshall
2020-05-24 20:42 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200517020535.GA3652@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=me@tobias.gr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).