Double indirection for userns=auto

[tangentsoft]

One of the problems with --userns=auto comes when you use it with a container that makes use of multiple IDs within it, preventing the --volume …:U flag from doing the right thing.

Another is that it makes debugging difficult on the host side: when looking at ls -l output on a mapped-in volume, you have to map high-valued UIDs back down to the actual ones outside.

I have no reason to suppose what i'm about to propose exists in any form, but I felt I needed to put it out there into the world regardless. It is this: what precludes having a double-indirection system around sub[ug]id ranges such that $UID-$UID+64k maps to 100000+ inside the kernel, but this then gets reverse-mapped to regular user IDs before files hit persistent storage?

If possible, it would mean :U isn't necessary. If the kernel gives a different UID range for a given container instance than the prior run, it simply goes through a different mapping, but the UID/GIDs on disk remain compatible.

[tangentsoft]

Partial answer to my own question: it's only safe for rootful containers because otherwise there's a risk of UID impersonation. My rootless user may have UID 1000, but it doesn't have the next 64k UIDs beyond that. If the container needs any of those, it needs the current system.

However, my question stands for the rootful case: if it grabs ~1024 users starting from 0 inside, but we want privilege isolation at the kernel level but for it to be smashed down to real local IDs at the filesystem level, what prevents the kernel from doing that other than the lack of code to make it so?

[Luap99]

I have no reason to suppose what i'm about to propose exists in any form, but I felt I needed to put it out there into the world regardless. It is this: what precludes having a double-indirection system around sub[ug]id ranges such that $UID-$UID+64k maps to 100000+ inside the kernel, but this then gets reverse-mapped to regular user IDs before files hit persistent storage?

It is called idmapped mounts and is supported a for a while now, -v /host:/container:idmap uses the same userns mapping as for the container, or you can even specify your own mappings see the "Idmapped mount" section https://docs.podman.io/en/latest/markdown/podman-create.1.html#volume-v-source-volume-host-dir-container-dir-options

[tangentsoft]

Aha! I do believe this is a reasonable test case of what you're telling me:

$ sudo podman run --userns=auto --user daemon --rm -it -v ~/tmp:/tmp:z,idmap \
  alpine bash -c 'sleep 10 ; \
  touch /tmp/x' ; \
  ls -l tmp/x ; \
  rm -f tmp/x
-rw-r--r--. 1 daemon daemon 0 Aug 18 01:12 tmp/x

Without the :idmap flag, you get whatever is configured for containers in /etc/subuid + 2, the fixed ID of the default daemon user.

I have tested this with overlapping instances to force multiple userns=auto ranges to be allocated, showing that it gets remapped back to "daemon" on the host each time.

Thank you!

[tobwen]

Sorry for a follow up, I actually have no clue, what this error means:

$ sudo podman run --userns=auto --rm -v ~/tmp:/tmp:z,idmap=uids=33-44-1 alpine \
  sh -c 'sleep 1; touch /tmp/x && chown 33:33 /tmp/x;'

touch: /tmp/x: Value too large for data type

$ sudo podman run --userns=auto --rm -v ~/tmp:/tmp:z,idmap=uids=44-33-1 alpine \
  sh -c 'sleep 1; touch /tmp/x && chown 33:33 /tmp/x;'

touch: /tmp/x: Value too large for data type

No matter what size you're giving in /etc/subuid, no matter, what value you set in idmap, with and without z on Debian 12.

[Luap99]

The problem seems to be that using a custom mapping like uids=33-44-1 is then fully separate from the main container user namespace mapping, i.e. it is not relative to each other.

As such you end up mapping uid 33 to 44 on the host. However uid 33 then is then the actual uid 33 on the host but since your container process runs in a userns that does not have uid 33 mapped it will never work as you try to write to it with some high uid instead.

Maybe this custom mapping show is easier:

sudo podman run --rm --uidmap 0:1000:1024 -v /tmp:/tmp:idmap=uids=0-1005-10 --user 10  quay.io/libpod/testimage:20241011 sh -c 'ls -l /tmp; touch /tmp/x'

And then /tmp/x has id 5 on the host while it has uid 10 in the container here.

The docs seems to be lacking here but there seems to be a way to force a relative mapping here with @ which I think is far more useful.

$ sudo podman run --rm --userns auto  -v ~/tmp:/tmp:z,idmap=uids=@33-44-1 --user 44  quay.io/libpod/testimage:20241011 sh -c 'touch /tmp/x; ls -ln /tmp/x'
-rw-r--r--    1 44       0                0 Aug 22 14:18 /tmp/x
$ sudo ls -ln tmp/x
-rw-r--r--. 1 33 0 0 22. Aug 16:18 tmp/x

Note that you must be user 44 to write here because in your example doing touch && chown cannot work as touch fails as it would try to write as a uid which was not mapped. If you want to do that you would need to give it a bigger range to be able to create fiules with different uids, i.e. consider this:

$ sudo podman run --rm --userns auto  -v ~/tmp:/tmp:z,idmap=uids=@33-0-45 --user 0  quay.io/libpod/testimage:20241011 sh -c 'touch /tmp/x; ls -ln /tmp/x; chown 44:44 /tmp/x; ls -ln /tmp/x; chown 99:99 /tmp/x;'
-rw-r--r--    1 0        0                0 Aug 22 14:23 /tmp/x
-rw-r--r--    1 44       44               0 Aug 22 14:23 /tmp/x
chown: /tmp/x: Value too large for data type
$ sudo ls -ln tmp/x
-rw-r--r--. 1 77 44 0 22. Aug 16:23 tmp/x

And yes I totally agree idmappings are hard to understand and we definably good need better docs with more examples around this