Support for large UIDs

[pendo324]

Describe the bug
Currently when trying to use a large UID inside a container, you will receive an error like:

FATA[0001] failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to setup user: invalid argument: unknown
FATA[0001] exit status 1

Steps to reproduce

1. Create a Dockerfile with a useradd command that creates a user with a large UID (the limit seems to be anything greater than 65535 or [2^16 - 1])

cat <<EOF >>Dockerfile
FROM ubuntu
RUN useradd -u 65540 repro
EOF

2. Build the image and run it (finch build -t repro . && finch run -it --rm repro)
3. su to the user with a large UID inside the container:

root@cef1f697437f:/# su repro
su: cannot set user id: Invalid argument

Expected behavior
Should be able to use the user inside the container

Screenshots or logs
If applicable, add screenshots or logs to help explain your problem.

Additional context
Just as an aside, this was originally reported to me by a user on Slack, so the repro condition may not exactly align with what they were doing. It's also debatable whether this is a bug or a feature request.

Initially, this seems to be related to the fact that Finch uses a rootless containerd setup.

[estesp]

Adding a comment so at least the current state is clear to users, and specifically, why high UIDs are not possible by default in Finch:

$ finch run -ti --rm alpine sh
/ # cat /proc/self/uid_map
         0        504          1
         1     100000      65536
/ # cat /proc/self/gid_map
         0       1000          1
         1     100000      65536
/ #

Inside the Lima VM, nerdctl (and of course containerd/buildkit/runc) are installed, and by default nerdctl installs rootlesskit and starts containerd in rootless mode. This means that subordinate UID/GID maps are in place when containers are running inside the Lima VM. By default on most (all?) Linux distros, the subordinate ranges for an ID are given out in 64K chunks (2^16-1); as you can see above the root ID inside the container is mapped to the macOS UID/GID pair (504:1000 for me), and then rest of the 64K ID space is rooted at 100000 for me. Once an ID is encountered above the 2^16-1 limit, the runtime will fail to map the ID to a valid UID or GID and fail.

Larger maps can be created, and potentially at Finch VM init the subordinate maps could be specified as one possible solution if there is a requirement to use large IDs.

[pendo324]

Since we own the VM, I wonder if we can just do something like

sudo usermod --add-subuids 100000-1000999999 $USER

in a provisioning script?

Here's some resources I found that might help debug/fix this issue:

• https://rootlesscontaine.rs/getting-started/common/subuid/
• https://wiki.gentoo.org/wiki/Subuid_subgid

The python program on the rootlesscontaine.rs website is interesting, but I haven't got around to trying it yet

[AkihiroSuda]

Issue on the upstream Lima:

• Extend the default subuid range from 64k to 1G lima-vm/lima#1227

[vsiravar]

This can be fixed by either modifying the /etc/subu{g}id file in a text editor or using the usermod command to increase userid count in the child namespace.

$ LIMA_HOME=/Applications/Finch/lima/data /Applications/Finch/lima/bin/limactl shell finch
$ sudo vi /etc/subuid
$ cat /etc/subuid
vsiravara:100000:200000
$ finch vm stop
$ finch vm start
$ finch build -t repro . && finch run -it --rm repro
root@ca653f00e5a1:/# su repro
$ whoami 
repro
$ id
uid=65540(repro) gid=1000(repro) groups=1000(repro)

However there maybe some side effects of increasing uid count inside a container and with overlapping mappings.

[pendo324]

We may want to consider adding this as a config option in Finch and/or Lima. It should be fairly simple to (optionally) run the usermod command as part of user provisioning in the CIDATA package.

[ningziwen]

Related issue. #80
Changing to rootful mode may also resolve this.

[ningziwen]

The large uid/guid issue was resolved by switching to rootful container inside VM. #196