Re: Unprivileged /gnu/store with PRoot

[Ludovic Courtès]

Hello!

Ricardo Wurmus <address@hidden> skribis:

> Ludovic Courtès <address@hidden> 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.

Exactly.  Many have written LD_PRELOADable libraries to perform file
system virtualization but it’s tedious (there are so many VFS-related
functions to interpose!) and fragile, and an application can always do a
direct syscall and bypass the thing.

So PRoot is not the preferred option, but it’s one we can resort to when
there’s no other option.  I have yet to measure its performance impact
when running some of the linear algebra software that people use/develop
here.

> More power to the Hurd on HPC!

:-)

Ludo’.