runsc: Allow map host user to non-root user in rootless mode

[terenceli]

Fix #9918.

Currently, the rootless mode(runsc is called by no-root user) is not working well with the filesystem if we uses a non-root user in runsc container. This is because the runsc is mapping the host non-root user to root-user in container.

In some cases we need to map the host non-root user to runsc container non-root user (with the same uid).

After this patch, the following filesystem operations works well.

test@test-virtual-machine:/test$ ./runsc -ignore-cgroups --network host run abc
id
uid=1000(test) gid=1000(test) groups=1000(test)
touch /tmp/runsctest
echo aaa > /tmp/runsctest
ls -lh /tmp/runsctest
-rw-r--r-- 1 test test 4 Jun 29 18:46 /tmp/runsctest
exit
test@test-virtual-machine:/test$ ls -lh /tmp/runsctest
-rw-r--r-- 1 test test 4 6月 29 18:46 /tmp/runsctest
test@test-virtual-machine:~/test$ cat /tmp/runsctest

[avagin]

I don't understand this check. Why should the current uid/gid match the container process uid/gid?

[terenceli]

I don't understand this check. Why should the current uid/gid match the container process uid/gid?

Yes, I'm not sure is this correct?

Here I add this check is to make sure "the host non-root user can only start container with the corresponding user that he maps to."

Here I think we should clarify "What the meaning if one non-root user start a container process using another user's UID?" Should we allow it? Maybe we should check how crun/podman does it.

[terenceli]

@avagin
It seems that crun do as follows:
https://github.com/containers/crun/blob/main/src/libcrun/linux.c#L4687-L4704

1. check if container root is mapped
2. if it is then seteuid to 0
3. if not uses the uid specified in 'process.user' section.

So for gVisor case, the confirm thing is that we don't need check mapped container UID with the 'process.user' uid.

There are some subtle thing to decide.
Should we here use the mapped container UID(my current patch) or
just check the root is mapped in container user ns and uses 0 or 'process.user' UID (like crun)?

[avagin]

I think we need to do the same thing that crun does.

Should we here use the mapped container UID(my current patch) or

This covers your case, but actually the current user is often non-mapped to the container user namespace.

[terenceli]

I think we need to do the same thing that crun does.

Just push a new revision.

Should we here use the mapped container UID(my current patch) or

This covers your case, but actually the current user is often non-mapped to the container user namespace.