Allow configuration of the idmap option #873
Description
/kind feature
Description
The recently added idmap option [1] always maps all NS uid/gid of the container to the real ones.
There are use cases where one wants to have a container with "full" 65536 uid/gid but only wants some uid/gids mapped to the real ones for filesystem access. This is already supported by the kernel and the mount-idmapped program but is not currently possible with podman/crun.
For example, I would like to mount a directory inside a container that has a namespaced root user but prevent that namespaced root user from creating files that will be owned by the real root. In this case, the namespaced root should not be mapped or at least not be mapped to the real root.
A workaround is to use mount-idmapped to create a restrictive idmapped mount first and then mount that into the container.
# The container should only ever be able to create files owned by uid/gid 1000 on the host.
# Create mapping where only real uid/gid 1000 is mapped to 31000
sudo mount-idmapped --map-mount b:1000:31000:1 $(pwd)/mnt $(pwd)/mnt2
sudo podman run --rm -it -v=$(pwd)/mnt2/:/mnt --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 0:0 alpine /bin/sh
~ $ touch /mnt/123
touch: /mnt/123: Value too large for data type
sudo podman run --rm -it -v=$(pwd)/mnt2/:/mnt --uidmap 0:30000:7000 --gidmap 0:30000:7000 --user 1000:1000 alpine /bin/sh
touch /mnt/123
~ $ ls -lah /mnt
total 0
drwxr-xr-x 1 1000 1000 6 Feb 11 17:23 .
dr-xr-xr-x 1 root root 12 Feb 11 17:23 ..
-rw-r--r-- 1 1000 1000 0 Feb 11 17:23 123
Describe the results you received:
It is not possible to configure the idmap mount option.
Describe the results you expected:
It should be possible to configure the idmap mount option (like mount-idmapped).
Output of podman version:
Client: Podman Engine
Version: 4.0.0-dev
API Version: 4.0.0-dev
Go Version: go1.17.6
Git Commit: 28ccb79b41553e31c5bf6e6460106f01f0317c6d
Built: Fri Feb 11 15:58:20 2022
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.24.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: /usr/bin/conmon ist in conmon 1:2.1.0-1 enthalten
path: /usr/bin/conmon
version: 'conmon version 2.1.0, commit: bdb4f6e56cd193d40b75ffc9725d4b74a18cb33c'
cpus: 16
distribution:
distribution: arch
version: unknown
eventLogger: journald
hostname:
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
- container_id: 65537
host_id: 2147483647
size: 2147483648
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
- container_id: 65537
host_id: 2147483647
size: 2147483648
kernel: 5.16.8-arch1-1
linkmode: dynamic
logDriver: journald
memFree: 4144631808
memTotal: 33577861120
networkBackend: cni
ociRuntime:
name: crun
package: /usr/bin/crun ist in crun 1.4.2-1 enthalten
path: /usr/bin/crun
version: |-
crun version 1.4.2
commit: f6fbc8f840df1a414f31a60953ae514fa497c748
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
path: /run/user/1000/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /etc/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: /usr/bin/slirp4netns ist in slirp4netns 1.1.12-1 enthalten
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.3
swapFree: 0
swapTotal: 0
uptime: 8h 51m 17.42s (Approximately 0.33 days)
plugins:
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
Package info (e.g. output of rpm -q podman or apt list podman):
**Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes