[Top][All Lists]

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

bug#40006: 33/33: daemon: Workaround issues for the Hurd.

From: Ludovic Courtès
Subject: bug#40006: 33/33: daemon: Workaround issues for the Hurd.
Date: Thu, 12 Mar 2020 13:59:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Jan Nieuwenhuizen <address@hidden> skribis:

> Ludovic Courtès writes:
> Hello!
>> Jan Nieuwenhuizen <address@hidden> 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.


reply via email to

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