unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Propose to distribute a user-only install script, not admin required
@ 2020-05-16 15:25 Josh Marshall
  2020-05-16 15:47 ` Tobias Geerinckx-Rice
  2020-05-24 20:42 ` Ludovic Courtès
  0 siblings, 2 replies; 5+ messages in thread
From: Josh Marshall @ 2020-05-16 15:25 UTC (permalink / raw)
  To: guix-devel

Hello all,

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.  Conceptually, guix shouldn't need to
have any elevated permissions given it is acceptable to use resources
less efficiently when they are in contention.  This would also allow
guix to be a drop in replacement to tools which already allow
individual users to install and use them without a hassle, like
Anaconda.

I'm not sure what all of the work required for this would be, or if it
is already in the long term plan.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Propose to distribute a user-only install script, not admin required
  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
  2020-05-24 20:42 ` Ludovic Courtès
  1 sibling, 1 reply; 5+ messages in thread
From: Tobias Geerinckx-Rice @ 2020-05-16 15:47 UTC (permalink / raw)
  To: Josh Marshall; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Propose to distribute a user-only install script, not admin required
  2020-05-16 15:47 ` Tobias Geerinckx-Rice
@ 2020-05-17  2:05   ` Bengt Richter
  2020-05-24 19:19     ` Josh Marshall
  0 siblings, 1 reply; 5+ messages in thread
From: Bengt Richter @ 2020-05-17  2:05 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Propose to distribute a user-only install script, not admin required
  2020-05-17  2:05   ` Bengt Richter
@ 2020-05-24 19:19     ` Josh Marshall
  0 siblings, 0 replies; 5+ messages in thread
From: Josh Marshall @ 2020-05-24 19:19 UTC (permalink / raw)
  To: Bengt Richter; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Propose to distribute a user-only install script, not admin required
  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-24 20:42 ` Ludovic Courtès
  1 sibling, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2020-05-24 20:42 UTC (permalink / raw)
  To: Josh Marshall; +Cc: guix-devel

Hi Josh,

Josh Marshall <joshua.r.marshall.1991@gmail.com> skribis:

> 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.  Conceptually, guix shouldn't need to
> have any elevated permissions given it is acceptable to use resources
> less efficiently when they are in contention.  This would also allow
> guix to be a drop in replacement to tools which already allow
> individual users to install and use them without a hassle, like
> Anaconda.

I think we should consider providing a binary tarball produced with
‘guix pack -RR’ instead of just ‘guix pack’.  It’s possible to run
“rootless” Guix from there:

  https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html

With minor changes to the daemon, we could arrange so that users don’t
have to fiddle with environment variables or anything.

Now, I fear that the typical use case for that is places where user
namespaces aren’t available, which means a degraded experience.  (See
the rant at the bottom of
<https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/>.)

Thoughts?

Ludo’.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-05-24 20:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2020-05-24 19:19     ` Josh Marshall
2020-05-24 20:42 ` Ludovic Courtès

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