linux: support options to idmap

[giuseppe]

allow to specify what mapping must be used for idmapped mounts.

The mapping can be specified after the idmap option like:
idmap=uids=0-1-10;gids=0-100-10.

When uids and gids are specified, then a new user namespace is
created and used for the bind mount.

Closes: #873

Signed-off-by: Giuseppe Scrivano [email protected]

[lukts30]

The current implementation is a bit problematic since it would be difficult to be used together with --userns=auto.
From my testing with this PR:

# Files created in the container in /mnt/ as namespaced root will be owned by root on the host. 
sudo podman run --rm -it --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 --mount=type=bind,src=$(pwd)/mnt2/,dst=/mnt,idmap alpine /bin/sh
# Files created in the container in /mnt/ as namespaced root will be owned by root on the host. (equivalent to omitting uids=.../gids=...)
sudo podman run --rm -it --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 --mount=type=bind,src=$(pwd)/mnt2/,dst=/mnt,idmap="uids=0-30000-7000;gids=0-30000-7000" alpine /bin/sh


# Files created in the container in /mnt/ as namespaced root will be owned by uid 1000 on the host. 
sudo podman run --rm -it --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 --mount=type=bind,src=$(pwd)/mnt2/,dst=/mnt,idmap="uids=1000-30000-7000;gids=1000-30000-7000" alpine /bin/sh

This behavior is more from the perspective of the underlying filesystem (on_disk_uid-host_uid-amount) than from the perspective of the container.
It is problematic since knowledge of the real/host uid (30000) of the namespaced uid 0 is required and practically it would be incompatible with --userns=auto if podman would pass the values unprocessed to crun.

---

The behavior that I would prefer is the same as --uidmap (container_uid-host_uid-amount) replacing host_uid with on_disk_uid (container_uid-on_disk_uid-amount).

# Files created in the container in /mnt/ as namespaced root will be owned by uid 1000 on the host. 
sudo podman run --rm -it --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 --mount=type=bind,src=$(pwd)/mnt2/,dst=/mnt,idmap="uids=0-1000-7000;gids=0-1000-7000" alpine /bin/sh

container user namespace [0,6999] --> Filesystem [1000,7999]

or alternatively described as:
Filesystem [1000,7999] --> initial user namespace/host [30000,36999]
/proc/[pid]/uid_map: "1000 30000 7000"

With this behavior omitting uids=.../gids=... should be equivalent to:

sudo podman run --rm -it --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 --mount=type=bind,src=$(pwd)/mnt2/,dst=/mnt,idmap="uids=0-0-7000;gids=0-0-7000" alpine /bin/sh

[giuseppe]

so you'd like that the specified uids= and gids= are relative to the container user namespace instead of using them directly.

This should be doable but adds some complexity, we need to deal with non-contiguous ranges, as well as handle an existing user namespace (e.g., podman run --userns ns:/proc/PID/ns/user) and read its configuration.

[lukts30]

so you'd like that the specified uids= and gids= are relative to the container user namespace instead of using them directly.

This should be doable but adds some complexity, we need to deal with non-contiguous ranges, as well as handle an existing user namespace

If a container user namespace is non-contiguous and unmapped ids are included in the idmap option then that should just return an error.

0 165536 7000
10000 200000 7000

(container_uid-on_disk_uid-amount)
idmap=0-1000-7000 ok
idmap=0-1000-7001 error

But a user namespace that is contiguous but its mapping is not contiguous should still just work.

0 165536 7000
7000 200000 7000

(container_uid-on_disk_uid-amount)
idmap=0-1000-14000 ok

---

I have tested the following with the unshare/newgidmap/nsenter commands (uses nested user namespaces).

1. Create child process (C0). child:

   • setns(userns_container,CLONE_NEWUSER)
   • wait on parent

2. parent:

   • capture /proc/c0_pid/uid_map
   • capture /proc/c0_pid/gid_map

3. C0 Exit

4. Create child process (C1) with CLONE_NEWUSER. parent:

   • write captured mapping to /proc/c1_pid/uid_map
   • write captured mapping to /proc/c1_pid/gid_map
   • (this creates a copy of userns_container as it is seen from the initial user namespace. making a copy since the user namespace created in step 5 should not be owned by userns_container. unsure if this is really needed)

5. Create child process (C2) with CLONE_NEWUSER inside C1 Process. C1:

   • run a helper programm that reads /proc/self/uid_map and prints the required mapping for C2. [1]
   • if the user namespace is contiguous this is equivalent to:
     • "on_disk_uid container_uid amount" > /proc/c2_pid/gid_map
     • "on_disk_uid container_uid amount" > /proc/c2_pid/gid_map

6. parent: sys_mount_setattr MOUNT_ATTR_IDMAP with the user namespace that was created in step 5.

---

Examples unshare/newgidmap/nsenter:

• contiguous userns but its mapping is not contiguous
• userns is not contiguous

[lgtm-com]

This pull request introduces 3 alerts when merging 9a1ab46 into d1acf9d - view on LGTM.com

new alerts:

• 3 for Wrong type of arguments to formatting function

[giuseppe]

I've added a new flag that can help you with your use case.

If you prepend + to a uids or gids mapping, then the mapping is considered relative to the container user namespace (as long as the mappings are specified in the OCI configuration). It doesn't split ranges, so it is the caller responsibility to do so.

$ sudo touch /foo && sudo chown 1:1 /foo
$ $ sudo podman run --mount "type=bind,src=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/foo,dst=/foo,idmap=uids=+1--1-100;gids=+0-0-100" --userns=auto --rm fedora stat -c '%u:%g' /foo
0:1

Would this work for you?

[lgtm-com]

This pull request introduces 3 alerts when merging 7ff74bf into d1acf9d - view on LGTM.com

new alerts:

• 3 for Wrong type of arguments to formatting function

[lukts30]

LGTM

[giuseppe]

finally centos:8 tests are green.

I think this is ready to merge

[flouthoc]

LGTM,

Just waiting for tests to pass.