[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential security weakness in Guix services
From: |
Ludovic Courtès |
Subject: |
Re: Potential security weakness in Guix services |
Date: |
Wed, 10 Feb 2021 21:45:58 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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’.
- Re: Potential security weakness in Guix services, (continued)
- Re: Potential security weakness in Guix services, Julien Lepiller, 2021/02/01
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/01
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/02
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/02
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/02
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/05
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/05
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/05
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/06
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/06
- Re: Potential security weakness in Guix services,
Ludovic Courtès <=
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/06
- TOCTTOU race (was: Potential security weakness in Guix services), Maxime Devos, 2021/02/14
- Re: TOCTTOU race (was: Potential security weakness in Guix services), Bengt Richter, 2021/02/14
- Re: TOCTTOU race, Ludovic Courtès, 2021/02/18
- Re: TOCTTOU race, Maxime Devos, 2021/02/19
- Re: TOCTTOU race, Ludovic Courtès, 2021/02/22
- Re: TOCTTOU race, Maxime Devos, 2021/02/22
- Re: TOCTTOU race, Ludovic Courtès, 2021/02/23
- Re: TOCTTOU race, Maxime Devos, 2021/02/27
- Re: Potential security weakness in Guix services, Christopher Lemmer Webber, 2021/02/10