all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: Ludovic Court??s <ludovic.courtes@inria.fr>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Unprivileged /gnu/store with PRoot - or relocate
Date: Sat, 13 May 2017 07:38:59 +0200	[thread overview]
Message-ID: <20170513053859.GA19841@thebird.nl> (raw)
In-Reply-To: <87d1beoyvi.fsf@gnu.org>

I explored this and actually built Nix/Guix on proot in the past for the
same reasons

  https://github.com/pjotrp/nix-no-root

Mind, it *is* slow. That is why I came up with relocatable Guix which
works much better. No performance loss. Just an extra installation
step. Relocatable Guix works great, but it requires effort to make it
user friendly. We can automate creating relocatable packages with guix
pack. All it needs is an additional installer that rewrites the paths.
The other limitation is that the installer prefix can be no longer
than ~50 characters because it gobbles up the Guix store path + hash.

I have written all the code for that. The installer is fast.

Anyone interested in that type of solution? We can make it work, even
as automated builds. I think it would be great for HPC and can even be
part of non-root packagers, such as brew and conda.

Pj.

On Fri, May 12, 2017 at 05:53:21PM +0200, Ludovic Court??s wrote:
> Hello Guix!
> 
> In hostile environments (read: machines that lack Guix and where you???re
> not root, such as HPC clusters), it can be hard to manage software with
> Guix.
> 
> We can use ???guix pack??? to build a bundle on one machine and ship it to
> the target machine.  But then, on the target machine, we need to be able
> to ???map??? the pack???s root directory to the root directory of the
> processes we run.
> 
> When user namespaces are enabled, this can be achieved with ???unshare???
> and ???chroot??? as shown at
> <https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html>.
> However user namespaces are often disabled by distros for lack of
> confidence in their security properties??.
> 
> One way to work around the problem is to use PRoot, a ptrace(2)-based
> tool to virtualize the file system??.  With the ???proot-static??? package I
> just pushed, one can run, say, hwloc, on such a hostile machine by
> sending locally-created packs as well as ???proot???:
> 
>   scp $(guix build proot-static)/bin/proot hostile:
>   scp $(guix pack hwloc -S /bin=bin) hostile:hwloc.tgz
> 
> and then on the hostile machine:
> 
>   mkdir ~/.local
>   cd ~/.local
>   tar xf ~/hwloc.tgz
>   cd
>   ./proot -b .local:/ /bin/lstopo
> 
> where ???proot -b .local:/??? essentially ???bind-mounts??? ~/.local to /.
> 
> Pretty cool no?  :-)
> 
> PRoot adds overhead since it has to intercept every syscall.  However,
> for a mostly computational process, it should not be much of a problem.
> 
> Ludo???.
> 
> ?? See for instance
>   <http://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/>
>   and the recent AF_PACKET vulnerability
>   <https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html>.
> 
> ?? https://github.com/proot-me/PRoot
> 

-- 

  parent reply	other threads:[~2017-05-13  5:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 15:53 Unprivileged /gnu/store with PRoot Ludovic Courtès
2017-05-12 16:20 ` Alex Sassmannshausen
2017-05-12 21:28 ` Hartmut Goebel
2017-05-13  5:38 ` Pjotr Prins [this message]
2017-05-13 14:12   ` Unprivileged /gnu/store with PRoot - or relocate Ludovic Courtès
2017-05-13  7:04 ` Unprivileged /gnu/store with PRoot Maxim Cournoyer
2017-05-13 14:02   ` Ludovic Courtès
2017-06-08 15:29 ` Ricardo Wurmus
2017-06-09  8:09   ` Ludovic Courtès
2017-07-16 12:35 ` Pjotr Prins
2017-07-16 12:51   ` Pjotr Prins
2017-07-16 16:09     ` Pjotr Prins

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

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

  git send-email \
    --in-reply-to=20170513053859.GA19841@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    /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 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.