6:05 a.m.
Thanks for taking the time to write this clarification, Erik.
I experimented a bit more with varying UID/GID mapping parameters to deepen my
understanding. The idea here was to try out different "from/intermediate UIDs"
as being positive offsets from the regular UID/GID of the user, such that they would fit
within the range of 65536 possible subordinate UIDs/GIDs for that user:
First the ones that didn't work (the CMD of the image, a chain of &&'d
commands culminating in gunicorn startup fails mid-chain, with 'pip install'
getting a "Permission denied" error):
--uidmap 0:65534:1
--uidmap 100:65535:1
--gidmap 0:65534:1
--gidmap 65534:65535:1
--uidmap 0:1:1
--uidmap 100:200:1
--gidmap 0:1:1
--gidmap 65534:200:1
--uidmap 0:1:1
--gidmap 0:1:1
(This last one would never have worked with 'apt update', but I was curious to see
if it would work for just the container root -> host user2 mapping, i.e. goal 1 from my
last post.)
Then the ones that DID work, achieving both goals 1 and 2 from my last post:
--uidmap 0:0:1
--uidmap 100:200:1
--gidmap 0:0:1
--gidmap 65534:200:1
--uidmap 0:0:1
--uidmap 100:65536:1
--gidmap 0:0:1
--gidmap 65534:65536:1
...and of course the original consecutive intermediate UID/GID version, from my last
post:
--uidmap 0:0:1
--uidmap 100:1:1
--gidmap 0:0:1
--gidmap 65534:1:1
So it seems like I have to have intermediate UID/GID 0 mapped, after which the later
intermediate UIDs/GIDs can be anything <= 65536 – no need to start them from 1.
It's quite likely that this is my lack of understanding of user namespaces again, but
this requirement for intermediate UID/GID 0 mapping to be present isn't obvious to me
from either the --uidmap documentation or from your extended explanation. Is it expected
behaviour and if so, why—or perhaps a Podman bug?