[bug#54997] [PATCH 00/12] Add "least authority" program wrapper

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:

> I'm a bit concerned about running arbitrary commands as PID 1 of process
> namespaces. A process running as PID 1 (even in a child namespace) is a
> special case and is treated differently by the Linux kernel than any
> other process, so it needs to be a program that has been designed to
> work in that situation. There are two differences from regular
> processes:
>
> 1. PID 1 inherits orphan processes and needs to wait() on them when they
>    quit, in order to avoid accumulating zombie processes in the system.
>
> 2. Unlike regular processes, PID 1 doesn't have default signal handlers.

Good points.

> Both of these aspects are described in more detail here:
>
> https://github.com/krallin/tini/issues/8#issuecomment-146135930
>
> So to avoid an accumulation of zombie processes and other signal-related
> problems, I suggest adding a “(init-program ,tini)” parameter to
> ‘least-authority-wrapper’ and executing ‘program’ as a subprocess of
> ‘tini’ or whatever was passed as the #:init-program (perhaps #f could
> mean running ‘program’ directly as PID 1).

Hmm yes.  It’s not great that the choice is between ‘unshare’—efficient
but the process lives in the parent PID namespace—and ‘clone’—but then
you have to fork twice.

But yeah, you’re right.  I’ll try what you suggest and send a v2.

> I mention this because I'm currently dealing with a problem that has
> exactly this root cause: I'm working on updating the public-inbox
> package to the latest version, and the testsuite is failing because it
> tests that lei's daemon process is correctly terminated. But that
> doesn't work because “guix build” doesn't use a proper init program as
> PID 1 and thus the daemon process goes to zombie state and the testsuite
> thinks that it didn't go away. I'm hoping to send a patch to fix that
> issue.

Now that you mention it, this was discussed before:

  https://issues.guix.gnu.org/30948

I think we should do something about it in gnu-build-system.scm.

Thanks for your feedback!

Ludo’.