guix-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Build sandbox support etc. unconditionally on Linux.


From: Ludovic Courtès
Subject: Re: [PATCH] Build sandbox support etc. unconditionally on Linux.
Date: Wed, 07 Sep 2016 10:14:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello Manolis!

Manolis Ragkousis <address@hidden> skribis:

> On 08/10/16 20:39, Mark H Weaver wrote:
>>
>> I'm very reluctant to apply this patch.  In general, it's preferable to
>> rely on autoconf to test for individual features, rather than testing
>> for particular kernels by name.  It seems to me that this patch will
>> hinder portability to other kernels.
>>
>> I'd be inclined to return to the approach you were proposing before
>> discovering this upstream patch.  I'll take a look at it soon.
>>
>> What do you think?
>
> Well the other solution will be to break the CHROOT_ENABLED into smaller
> macros, depending on what we check.  If you think this is a better
> solution then okay with me.
>
> Locally I broke CHROOT_ENABLED into
>
> #define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H &&
> defined(MS_BIND) && defined(MS_PRIVATE)
> #define CLONE_ENABLED defined(CLONE_NEWNS)
> #if defined(SYS_pivot_root)
> #define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,
> put_old))
> #endif

That sounds preferable, or maybe just avoid CHROOT_ENABLED altogether?

> And maybe we should rename CHROOT_ENABLED into SANDBOX_ENABLED or
> something similar to better describe its purpose.

I’d rather not (Nix made this change, but that’s largely because OS X
has a similar feature called “sandbox”, so they used this name in the
code.)

Ludo’.



reply via email to

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