bug-guix
[Top][All Lists]
Advanced

[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)

Hi!

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.

Thanks,
Ludo’.





reply via email to

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