--userns=keep-id:uid=1000,gid=1000 also changes container init process user #24934
Comments
|
Another way of illustrating this, by inspecting the running containers instead of the output of guillaume@framework:~$ podman run --rm -d --name test fedora:latest sleep infinity
53123d4230e51a4d8ccee1f1267fd38d68baf7e8273fd934cc01e91b67984d32
guillaume@framework:~$ podman inspect -f "{{.Config.User}}" test
guillaume@framework:~$ podman inspect -f "{{.HostConfig.IDMappings}}" test
<nil>
guillaume@framework:~$ podman kill test
test
guillaume@framework:~$ podman run --rm -d --name test --userns=keep-id:uid=1000,gid=1000 fedora:latest sleep infinity
0eec56df2cffe69bf4590465b4b799774183be04eb4ca337abcef3b17611f4a9
guillaume@framework:~$ podman inspect -f "{{.Config.User}}" test
1000:1000
guillaume@framework:~$ podman inspect -f "{{.HostConfig.IDMappings}}" test
{[0:1:1000 1000:0:1 1001:1001:64536] [0:1:1000 1000:0:1 1001:1001:64536]}
guillaume@framework:~$ podman kill test
test
guillaume@framework:~$ podman run --rm -d --name test --uidmap=0:1:1000 --uidmap=1000:0:1 --uidmap=1001:1001:64536 --gidmap=0:1:1000 --gidmap=1000:0:1 --gidmap=1001:1001:64536 fedora:latest sleep infinity
a68187c2275a32b0b85785a1d09a8c413193e7c642cf331e6c6ff3998cbf5328
guillaume@framework:~$ podman inspect -f "{{.Config.User}}" test
guillaume@framework:~$ podman inspect -f "{{.HostConfig.IDMappings}}" test
{[0:1:1000 1000:0:1 1001:1001:64536] [0:1:1000 1000:0:1 1001:1001:64536]}
guillaume@framework:~$ podman kill test
test |
|
Sidenote: Here is a workaround. Use the The resulting /proc/self/uid_map and /proc/self/gid_map are the same The container process is running as root |
|
Thanks a lot for the workaround @eriksjolund ! That works just like I wished 👌 |
I also prefer the Another thing: I noticed a small difference between Result:
|
It is at the moment, but I think it shouldn't be, right? Or at least I hope that the guillaume@fedora:~$ podman pod create --pod-id-file /tmp/test.pod-id test
e0f1d096c9fcbcb4887a603750618e5352033f5f874d385b695ce809cbf41a4d
guillaume@fedora:~$ podman run --rm --userns=keep-id:uid=1000,gid=1000 --pod-id-file /tmp/test.pod-id fedora:latest id
uid=1000(guillaume) gid=1000(1000) groups=1000(1000)
guillaume@fedora:~$ podman run --rm --uidmap +1000:0:1 --gidmap +1000:0:1 --pod-id-file /tmp/test.pod-id fedora:latest id
Error: cannot specify a new uid/gid map when entering a pod with an infra container: invalid argumentYet another thing, it can be used with a pod, but only using the guillaume@fedora:~$ podman run --rm --userns=keep-id:uid=1000,gid=1000 --pod test fedora:latest id
Error: --userns and --pod cannot be set together |
These are just bugs as the restriction was implemented poorly, you should not be able to nest user namespace options when in a pod as this well mess up a ton of things. Mostly permissions on the various shared file systems. The behavior of userns=keep-id to change the user is intentional, it will even add a /etc/passwd entry for your local user name as the goal of this option was to sort of "leak" the current user with the same uid in the container so you could treat it like being on the real host. We should definitely update the docs though to mention the user overwrite behavior. |
Luap99
added
documentation
|
Okay, thanks for the clarification, so the desired option for me stays the manual mapping (made more handy with the
Regarding the weak restrictions on the nested userns, could you be more specific as to which shared file systems could have issues? If I managed to make my containers start using such option that shouldn't be available, and they all seem to be working fine, what type of issues should I expect? The only thing I can think about is the shared network stack, and the |
Yes that is one, I think if the ipc namesapce is shared we share /dev/shm and the permissions there would also be different. I don't have time to dig through the history right now to find the exact reasons the check was added so there might be more.
Well I would argue the current way we restrict this is wrong, either we fully restrict it (breaking change so not without a major 6.0 release) or we loose that restriction and then leave the possible problems to user to figure/out deal with. I can be convinced for either one but the current limitation of blocking only a few flag combination is just silly and I rather get this fixed properly at some point. |
Issue Description
I like to run multiple applications in podman containers, and persist the storage using bind mounts. I run all these containers rootless, and always make sure that the user of the process inside the container that is producing the data will match the user running the container on the host (using id mapping).
I recently happily discovered that
--userns=keep-idwas accepting some uid and gid options, allowing me to stop doing my uid mappings by hand with--uidmapand--gidmap(repeating them three times to make sure to have the full subuid/subgid ranges mapped)It all looked good, until I realized that this userns mode was doing more than what I understood from the documentation, it also changes the user that will start the initial process in the container.
To me, it looks like that is not a desired behavior. Is it?
Steps to reproduce the issue
To illustrate my point, let's start the fedora container, with all the default options, and check the user of the initial process. Without a surprise, it is root:
Now let's use uid/gid mapping, it is still root:
Now, let's use the userns option with keep-id, to my surprise, my host username suddenly exists inside the container (surprising but ok), and it is the user of the main process of the container, while I still expected root:
If I use the
--useroption, things go back to "normal", but the annoyance is that I am also overwriting the default specified by the container image I am using:Describe the results you received
Using
--userns=keep-id,uid=...,gid=...changes the default initial process user inside the containerDescribe the results you expected
I would expect that
--userns=keep-id,uid=...,gid=...doesn't impact the default initial process user inside the containerpodman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: