[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’.