all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: 33/33: daemon: Workaround issues for the Hurd.
Date: Wed, 11 Mar 2020 15:50:26 +0100	[thread overview]
Message-ID: <87h7yvgd3h.fsf@gnu.org> (raw)
In-Reply-To: <87k13s2wwl.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Tue, 10 Mar 2020 13:54:02 +0100")

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>>> +#if !__GNU__
>>>      int status = pid.wait(true);
>>>      if (status != 0)
>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>> +#endif
>>
>> Do you know what the rationale was?  It looks like it could leave
>> zombies behind us.
>
> No, maybe Manolis knows?  What I do know is why I used the patch: before
> applying this patch I could only build up to binutils-boot0.
> binutils-boot0 would always fail like so
>
>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>     XXX fails: Workaround for nix daemon
> phase `compress-documentation' succeeded after 0.4 seconds
> error: cannot kill processes for uid `999': Operation not permitted
> guix build: error: cannot kill processes for uid `999': failed with exit code 1

But is the build process actually running as UID 999?  If you pass
‘--disable-chroot’, then I think build users are not used at all, right?

> From 0307646b22fc488e6342f5814fdef336dd154be3 Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis <manolis837@gmail.com>
> Date: Sun, 7 Aug 2016 17:48:30 +0300
> Subject: [PATCH 1/2] daemon: Break CHROOT_ENABLED into smaller macros.
>
> Checking for CLONE_NEWNS is only needed for using tha Linux specific clone(2),
> otherwise we can use fork(2).
>
> * nix/libstore/build.cc (CHROOT_ENABLED): Break into CHROOT_ENABLED
> and CLONE_ENABLED.
> (DerivationGoal::startBuilder): Replace CHROOT_ENABLED with CLONE_ENABLED.
> (DerivationGoal::runChild): Only define pivot_root() if SYS_pivot_root is
> defined.

[...]

> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
> +#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
>  
>  #if CHROOT_ENABLED
>  #include <sys/socket.h>
> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
>         - The UTS namespace ensures that builders see a hostname of
>           localhost rather than the actual hostname.
>      */
> -#if CHROOT_ENABLED
> +#if CLONE_ENABLED
>      if (useChroot) {
>  	char stack[32 * 1024];
>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;

I’m not sure this is correct.  Perhaps we rather need an “#ifdef
__linux__” around the use of clone(2)?

Other options:

  1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.

  2. Add a “sandbox” abstraction in the daemon, with OS-specific
     implementations of the abstraction (the Nix daemon did that at some
     point, with the goal of supporting proprietary macOS etc.)

     For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.

     On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
     its own proc server, root file system server, and without a pfinet
     server running.

Option #2 can be fun to implement and probably easier and less
controversial than Option #1.  However, it does mean adding more code of
the C++ code base, which is sad.

Either way, it’s a bit of work, so this can definitely come later.

Ludo’.

  reply	other threads:[~2020-03-11 14:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200310075832.7126.86402@vcs0.savannah.gnu.org>
     [not found] ` <20200310075845.291F421123@vcs0.savannah.gnu.org>
2020-03-10  8:54   ` 08/33: gnu: make: Revert to 4.1 for the Hurd Ludovic Courtès
2020-03-10  9:16     ` Jan Nieuwenhuizen
     [not found] ` <20200310075844.240A021123@vcs0.savannah.gnu.org>
2020-03-10  8:55   ` 05/33: gnu: hurd: Fix hurd-target? Ludovic Courtès
2020-03-10 11:22     ` Jan Nieuwenhuizen
     [not found] ` <20200310075846.1DA6821123@vcs0.savannah.gnu.org>
2020-03-10  9:02   ` 11/33: gnu: glibc: Add and update patches for the Hurd Ludovic Courtès
2020-03-10 11:28     ` Jan Nieuwenhuizen
     [not found] ` <20200310075853.45FCC21252@vcs0.savannah.gnu.org>
2020-03-10  9:04   ` 33/33: daemon: Workaround issues " Ludovic Courtès
2020-03-10 12:54     ` Jan Nieuwenhuizen
2020-03-11 14:50       ` Ludovic Courtès [this message]
2020-03-12  6:59         ` Jan Nieuwenhuizen
2020-03-12 12:59           ` bug#40006: " Ludovic Courtès
2020-03-12 12:59           ` Ludovic Courtès
2020-03-12  6:59         ` bug#40006: " Jan Nieuwenhuizen
     [not found] ` <20200310075847.6059A2112F@vcs0.savannah.gnu.org>
2020-03-10  9:06   ` 15/33: gnu: coreutils: Remove libcap dependency " Ludovic Courtès
2020-03-11 15:01     ` Jan Nieuwenhuizen
2020-03-11 18:09       ` Vincent Legoll
2020-03-11 19:43         ` Jan Nieuwenhuizen
2020-03-12 13:01       ` Ludovic Courtès
2020-03-14  8:28         ` Jan Nieuwenhuizen
2020-03-14  8:28         ` bug#40006: " Jan Nieuwenhuizen
     [not found] ` <20200310075851.4497E2125F@vcs0.savannah.gnu.org>
2020-03-10  9:10   ` 27/33: gnu: commencement: glibc-intermediate: Build fixes " Ludovic Courtès
2020-03-10 12:45     ` Jan Nieuwenhuizen
     [not found] ` <20200310075850.035F02125B@vcs0.savannah.gnu.org>
2020-03-10  9:13   ` 23/33: gnu: commencement: gcc-boot0: Build fix " Ludovic Courtès
2020-03-10  9:18     ` Efraim Flashner
2020-03-10 13:53       ` Jan Nieuwenhuizen
2020-03-11 14:27         ` Jan Nieuwenhuizen
2020-03-11 15:14           ` Efraim Flashner
2020-03-11 16:20             ` Jan Nieuwenhuizen
2020-03-11 16:27               ` Efraim Flashner
2020-03-12  7:02                 ` Jan Nieuwenhuizen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7yvgd3h.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=janneke@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.