Document that in rootless mode, uidmap is in terms of the default mapping, not host uids

[rkjnsn]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I have a container that accesses a device as a non-root user (in the container) that I'm trying to run as a non-root user (outside of the container). To have access to the device, I need that user in the container, not root, to be mapped to my user ID, but I still need the containers entry point to be started as uid 0 (in the container).

It seemed this should be doable with --uidmap, which is documented as mapping container uids to host uids, so I kept trying variants of --uidmap=0:1065536:1000 --uidmap=1000:1000:1 --uidmap=1001:1066536:64536 to no avail. (My user's subuid entry is 1065536:65536).)

After, a lot of poking, prodding, reading random bugs, and playing with --userns=keep-id (which I can't use in this case, since I still need the entry point started as container uid 0, and which wouldn't work in the general case anyway, since my host uid and the relevant container uid aren't guaranteed to match), I eventually discovered that, when running rootless, the provided uidmap is actually applied after the default uidmap has already been applied, so what I actually needed to specify was --uidmap=0:1:1000 --uidmap=1000:0:1 --uidmap=1001:1001:64536 to get the mapping I wanted, which is not at all what I would expect from reading the documentation.

If this is, in fact, the intended behavior, the podman-run man page should be updated to explain how uidmap works in rootless mode. If this is not the intended behavior, I guess consider this a bug report for uidmap rather than a documentation bug. 🙂

Additional information you deem important (e.g. issue happens only occasionally):
If it's relevant, I'm using cgroups v2.

Output of podman version:

Version:            1.9.0
RemoteAPI Version:  1
Go Version:         go1.13.10
Built:              Tue May  5 17:23:34 2020
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.13.10
  podmanVersion: 1.9.0
host:
  arch: amd64
  buildahVersion: 1.14.8
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.15, commit: 1bddbf7051a973f4a4fecf06faa0c48e82f1e9e1'
  cpus: 8
  distribution:
    distribution: gentoo
    version: unknown
  eventLogger: journald
  hostname: rkjnsn-laptop-linux
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1065536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1065536
      size: 65536
  kernel: 5.4.28-gentoo
  memFree: 4033044480
  memTotal: 16663584768
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.3.0
  swapFree: 17042067456
  swapTotal: 17179693056
  uptime: 113h 30m 26.53s (Approximately 4.71 days)
registries:
  search:
  - docker.io
  - quay.io
  - registry.fedoraproject.org
store:
  configFile: /home/rkjnsn/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: Unknown
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/rkjnsn/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/rkjnsn/.local/share/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):
Physical Gentoo machine

[mheon]

I think this sounds like how things should work, so this is just a matter of documentation.

[mheon]

@giuseppe Mind taking a crack at this?

[giuseppe]

@mheon yes sure.

@rkjnsn it would take me a while before I get to work on this issue, would you like to improve the documentation with your findings and submit a PR? I'll be happy to review it

[rhatdan]

I am wondeing in rootless mode if we are doing this incorrectly.

I believe it would be a lot easier to understand if everything was relative to the current user namespace.

Example if I am in rootless mode

podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536

Then if I run a container
podman run --uidmap 0:10000:1000

Then this would setup a container with user map of
0 10001 1000

I would think this is a lot easier to underand and comes closer to what users would expect. Rather then failing always.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@giuseppe Any change you had time to play with this?

[akvadrako]

It would also be useful to keep uidmap relative to the default uidmap because you can specify the "current user" in a uidmap. For example, to run a container as user 100 and mapping it to the current user, you could do:

podman run --user=100 --uidmap=100:0:1

[rhatdan]

@giuseppe PTAL