Alternative to --userns=keep-id to map rootless user to the container user?

[wshanks]

I recently discovered this tip added to troubleshooting.md about mapping the rootless user's UID to the UID of the user in the container. I find this very useful for containers where the container user does not match my UID (my use case is that I can volume mount a directory into the container and continue to edit the files on the host system for development purposes without chowning them between my UID and the namespace's UID or copying them in again). For cases where my UID does match the container's UID, --userns=keep-id fits the role already. I wonder if it would be generally useful enough to make this an alternative to keep-id (map-id?) that is built in to podman.

[rhatdan]

You want the UID of the container to match your users UID?

Key	Host User	Container User
default	1000	0
keep-id	1000	1000
map-id	1000	999 (Assuming the container is running as User 999)?

Is that what you want?

I was also thinking a nomap would be useful.

nomap 1000 NOT MAPPED to container.

[wshanks]

Yes, that is right.

I work with one container where the default user is set to 1002 and on my laptop my user is 1000. I volume map one directory into the container to work with and edit files in it from the host with vim. From the troubleshooting guide, I realized I can use:

podman run --rm -it --user 1002 --uidmap 1002:0:1 --gidmap 1002:0:1 --uidmap 0:1:1002 --gidmap 0:1:1002 --uidmap 1003:1003:64534 --gidmap 1003:1003:64534 ...

to make this easy. Before that, I would toggle between podman unshare chown -R 1002:1002 and podman unshare chown -R 0:0 for when I was editing the files and using them in the container.

[rhatdan]

@giuseppe @mheon @vrothberg @baude @nalind @mtrmac WDYT?

[mheon]

I can see value to matching the user the container is actually running as to the user running Podman. I do question nomap, though - who would actually use it?

[rhatdan]

From a security point of view nomap, would protect your homedir from the content in a container. Basically no procesess within the container would be your UID so even if they broke out they would not be allowed to read $HOME/.ssh directory from a Usernamespace point of view.

[vrothberg]

I have a hard time imagining how the host's UID would be mapped into the container without keep-id. @rhatdan do you see a scenario other than an exotic /etc/subuid?

[rhatdan]

Not sure I am understanding the question. The host (user) UID is always mapped into user containers currently either defaulted to UID=0 or UID=$UID

Key	Host User	Container User
default	1000	0
keep-id	1000	1000
map-id	1000	999 (Assuming the container is running as User 999)?
nomap	1000	NOT MAPPED

[vrothberg]

I probably misinterpreted the question. I understood that nomap would prevent 1000->1000 (which only happens with keep-id). 1000->nil makes more sense.

[rhatdan]

Key	Host User	Container User
default	1000	0
keep-id	1000	1000
map-id	1000	999 (primary user of container)
nomap	1000	nil (Host User UID not mapped into container)

[giuseppe]

Would auto be enough? It picks an unique range where the current user is not mapped into

[rhatdan]

Yes I plan on documenting that, but auto is limited in that it wants to run each container in its own USERNS, and you quickly run out of containers. Probably less then 50 containers totally and 0 autocontainers if user specifies one with keep-id.