Allow configuration of the idmap option

[lukts30]

/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

[rhatdan]

@giuseppe PTAL

[giuseppe]

I've not originally implemented it for crun because allowing a different mapping would mean having to create a separate user namespace.

If we want to support this case, how would we pass down the information to the OCI runtime? Something like the following?

    {
      "destination": "/foo",
      "type": "bind",
      "source": "/foo",
      "options": [
        "idmap:uidmap=0:30000:7000;gidmap=0:30000:7000:7000:100000:1",
        "rw",
        "rprivate",
        "bind"
      ]
    }

[giuseppe]

moving to crun since it must be implemented here first

[giuseppe]

opened a PR for crun: #874

[giuseppe]

and for podman: containers/podman#13228

and containers/common: containers/common#927