Re: Potential security weakness in Guix services

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

> On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote:
>> Maxime Devos <maximedevos@telenet.be> skribis:
>> 
>> I just remembered this subtlety: during bootup, the activation code is
>> evaluated by the Guile that’s in the initrd, which is a
>> statically-linked Guile, and thus we can’t use ‘dynamic-link’ & co. in
>> there.  :-/
>
> I remember trying to use make-forkexec-constructor/container from activation
> code, which didn't work, due to some uses of dynamic-func ...  I see two
> possible options to take:
>
> * extend gnu/packages/patches/guile-linux-syscalls.patch with, say,
>   a "%extra-function-pointers" procedure returning a vector (or alist,
>   or something else) of pointers to the relevant C functions.  This
>   allows us to write the FFI code mostly in Scheme, and only write C
>   code for obtaining function pointer.
>
> * extend gnu/packages/patches/guile-linux-syscalls.patch with
>   additional bindings, or write a patch extending guile itself with
>   fchownat
> and other *at support.  This (second) patch should be
>   submitted upstream, but can be kept in gnu/packages/patches until
>   support for *at
> functionality makes it upstream.

Like I wrote earlier in <87zh0gzy52.fsf@gnu.org>, I think we can fix
this particular issue (‘mkdir-p/perms’) without resorting to the *at
functions, and I think that’s what we should do.

Support for *at will be useful, especially if we can make it part of
Guile proper, but it’s not an absolute prerequisite for the issue at
hand.

WDYT?

Thanks for looking into this!

Ludo’.