(u|g)idMappings should not exist when joining an existing user ns

[lifubang]

Description

When reviewing #3985, we found an error when joining an existing user namespace.
Ref: #3985 (comment)

Steps to reproduce the issue

1. start a container test with user mapping, for example:
   .linux.namespaces += [{"type": "user"}]
   .linux.uidMappings = [{"hostID": 100000, "containerID": 0, "size": 65536}]
   .linux.gidMappings = [{"hostID": 100000, "containerID": 0, "size": 65536}]

2. get the container init process's pid
   runc ps test
   for example the pid is 14821

3. start an new container test1 with pid 14821's user namespace, for example:
   .linux.namespaces += [{"type": "user", "path": "/proc/14821/ns/user"}]

Describe the results you received and expected

Received:
ERRO[0000] runc run failed: User namespaces enabled, but no uid mappings found.

Expected:
The container should be started successfully.

What version of runc are you using?

all

Host OS information

NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Host kernel information

Linux codespaces-21ad96 6.2.0-1016-azure #16~22.04.1-Ubuntu SMP Tue Oct 10 17:11:51 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[cyphar]

There's another problem -- we don't check that uidMappings/gidMappings are nil if you've used a path. You should only be able to set one of them. The time namespace validator has a similar issue.

I'll make a PR for this.

EDIT: Ah, this isn't an issue in the validator. The problem is that HostUID doesn't work if you have a userns path. That is extremely unfortunate... There is an obvious solution (join the userns and look at /proc/self/[ug]id_map but it's incredibly ugly -- and it doesn't help that Go doesn't even let you do this with with os.CreateProcess (you can only create namespaces, not join them).

[cyphar]

I have a patch for this, but in writing tests I found two separate issues:

1. Starting a container using the mount namespace of another container doesn't work for a few reasons. Some of them can be worked around (obviously you need to remove all mounts entries, as well as stuff like linux.maskedPaths and linux.readonlyPaths) but the core issue is that we unconditionally pivot-root into the rootfs and you cannot have an empty root section. So, if the target mount namespace has a different root, you will not be able to use it as the namespace to join for a new container.
2. It seems that userns and timens are incompatible. I'm not sure why our rootless integration tests work, but if you create a proper userns+timens, nsexec errors out when trying to write to /proc/self/timens_offsets with -EACCES (specifically the open fails, not the write so there's some permission issue with userns).

I'm still debugging 2. For 1, I don't really know how much there is to do -- maybe it's fair to say that we just don't support that use-case? @kolyshkin?

[lifubang]

I think we should backport the PR to release-1.1.

[lifubang]

@cyphar In the commit 09822c3, you fix the validation issues about user namespace and time namespace, but I think time namespace has not been supported in release-1.1. What should we do when we are doing cherry-pick this commit to release-1.1? Also backport #3876 or remove the code about time namespace when doing cherry-pick?

[cyphar]

@lifubang We would only need to backport the userns changes. That being said, I'm not sure whether we plan to have a 1.1.11 release. If we do, we should backport the fix, so I tagged it as such.