unofficial mirror of bug-guix@gnu.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, 40006@debbugs.gnu.org
Subject: bug#40006: 33/33: daemon: Workaround issues for the Hurd.
Date: Thu, 12 Mar 2020 13:59:55 +0100	[thread overview]
Message-ID: <8736advid0.fsf__2676.91060887358$1584018084$gmane$org@gnu.org> (raw)
In-Reply-To: <87o8t2qcso.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Thu, 12 Mar 2020 07:59:03 +0100")

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> 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?
>
> It seems that they are; I'm running

Oh, OK.

[…]

>> 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.
>
> I'm assuming that 1.is what Manolis wanted to support with his
> libhurdutil?  In fact, I forward ported (minimal effort) the patch
>
>     https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56
>
> but haven't tried linking against this yet.  That would be a nice first
> step.  2. sounds fun, but it would need more getting familiar with the
> Hurd for me :-)  You never know..

I suppose the commit you link to could have been used by libc to
implement #1?  Oh, actually, IIRC, Manolis was working on implementing
mount(2) and umount(2) in libc (which would also be needed), and
probably the settrans utilities were part of that effort.

Thanks,
Ludo’.

  parent reply	other threads:[~2020-03-12 13:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200310075832.7126.86402@vcs0.savannah.gnu.org>
     [not found] ` <20200310075853.45FCC21252@vcs0.savannah.gnu.org>
     [not found]   ` <87v9ncwpg4.fsf@gnu.org>
     [not found]     ` <87k13s2wwl.fsf@gnu.org>
     [not found]       ` <87h7yvgd3h.fsf@gnu.org>
2020-03-12  6:59         ` bug#40006: 33/33: daemon: Workaround issues for the Hurd Jan Nieuwenhuizen
     [not found]         ` <87o8t2qcso.fsf@gnu.org>
2020-03-12 12:59           ` Ludovic Courtès [this message]
     [not found] ` <20200310075847.6059A2112F@vcs0.savannah.gnu.org>
     [not found]   ` <87r1y0wpdj.fsf@gnu.org>
     [not found]     ` <87h7yvszpm.fsf@gnu.org>
     [not found]       ` <87y2s5u3ql.fsf@gnu.org>
2020-03-14  8:28         ` bug#40006: 15/33: gnu: coreutils: Remove libcap dependency " 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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to='8736advid0.fsf__2676.91060887358$1584018084$gmane$org@gnu.org' \
    --to=ludo@gnu.org \
    --cc=40006@debbugs.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).