Fix PID namespace support check

[edolstra]

Motivation

Fixes #7783 by actually checking whether /proc can be remounted in a mount+PID namespace.

Includes some refactoring to add clone() support to startProcess().

Context

Checklist for maintainers

Maintainers: tick if completed or explain if not relevant

• agreed on idea
• agreed on implementation strategy
• tests, as appropriate
  • functional tests - tests/**.sh
  • unit tests - src/*/tests
  • integration tests - tests/nixos/*
• documentation in the manual
• code and comments are self-explanatory
• commit message explains why the change was made
• new feature or incompatible change: updated release notes

[roberth]

Did you try to write a NixOS test for this?

[edolstra]

Yeah I've repurposed the remote-build test for this.

[useranon350]

This seems to cause issues when following https://nixos.wiki/wiki/Installing_from_Linux. I am getting "error: this system does not support the kernel namespaces that are required for sandboxing; use '--no-sandbox' to disable sandboxing" when running NIX_PATH="nixpkgs=channel:nixos-23.11" nixos-install from within a chroot or unshare -R session. I can use pid namespaces outside of a chroot. I have confirmed that unshare -fp --keep-caps --mount-proc=proc works, and allows further ``mount -t proc none proc``` calls.

EDIT: Running unshare -pfm --propagation unchanged bash followed by mount -t proc none proc from within the chroot also seems to work fine. Maybe it's actually because user namespaces aren't allowed within chroots? (i.e. unshare -r fails)

[useranon350]

I was able to solve the problem by using the pivot_root method with an additional step of unshare -m --propagation unchanged and mount --bind . . prior to starting the pivot. chroot and unshare -R both caused spurious issues with remounting /proc and legitimate issues with mount namespaces, although I think the latter were a result of my / not being a mountpoint. (Specifically, they wouldn't allow setting the mount propagation to rprivate on the new /.)

I think this could be resolved with a documentation update.