* 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 external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.