Re: Unprivileged /gnu/store with PRoot

[Ricardo Wurmus <rekado@elephly.net>]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> 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?  :-)

That *is* very cool indeed!

> PRoot adds overhead since it has to intercept every syscall.  However,
> for a mostly computational process, it should not be much of a problem.

Can this be simplified?  We really only need that user-space bind-mount
feature, nothing else.  PRoot does more than that IIUC.  Can we preload
a little library that provides “open” and implementations of other file
access procedures, and simply (I know…) changes any access of “/gnu”
with the new target directory?

I suspect this is doomed to fail because of the way shebangs work and
because we cannot interpose internal glibc calls, though.  Ultimately,
ptrace really is what we want on Linux and sadly it’s just slow.

More power to the Hurd on HPC!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net