[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potential security weakness in Guix services

From: Maxime Devos
Subject: Re: Potential security weakness in Guix services
Date: Sat, 06 Feb 2021 23:01:49 +0100
User-agent: Evolution 3.34.2

On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote:
> Maxime Devos <> 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
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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]