Re: Potential security weakness in Guix services

[Maxime Devos]

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.

The first option is the path I would find the most convenient myself
(though I'll probably write C code for parsing struct stat, as its
layout apparently varies much with kernel (Linux / Hurd) and
architecture), but the latter seems the way to go to prevent duplicate
effort upstream later on.

My C is a little rusty, but I'll have a try at the latter.

Maxime.

signature.asc
Description: This is a digitally signed message part