Error running Podman with --uidmap to non-root container user #11922

merusso · 2021-10-11T17:51:41Z

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

/kind bug

Error running Podman with --uidmap to non-root container user

I'm wanting to run a rootless container with a non-root UID (1001) that's mapped back to my host UID (1000).

Following the directions from the Podman run documentation

Even if a user does not have any subordinate UIDs in /etc/subuid, --uidmap could still be used to map the normal UID of the user to a container UID by running podman run --uidmap $container_uid:0:1 --user $container_uid ...

...I should only need to specify --user 1001 --uidmap=1001:0:1, but this returns the error result below.

Steps to reproduce the issue:

$ podman run --user 1001 --uidmap=1001:0:1 docker.io/library/ubuntu:focal

Describe the results you received:

Error: container uses ID mappings ([]specs.LinuxIDMapping{specs.LinuxIDMapping{ContainerID:0x3e9, HostID:0x0, Size:0x1}}), but doesn't map GID 0

Describe the results you expected:

Run container successfully, with container user 1001 mapped to host user 1000.

Additional information you deem important (e.g. issue happens only occasionally):

I don't get this error when adding either of the following:

--uidmap=0:1:1000
--gidmap=0:0:1

These arguments are mutually exclusive. If I run both, I get the following:

Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

Of these workarounds, --gidmap seems more appropriate given the error message "doesn't map GID 0", but when I run this, I get the following error in podman top:

$ podman top $containerName user huser
Error: error executing "nsenter -U -t 1 cat /proc/1/status": exit status 1

Output of podman version:

$ podman version
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Wed Dec 31 18:00:00 1969
OS/Arch:      linux/amd64

Output of podman info --debug:

$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.30, commit: '
  cpus: 1
  distribution:
    distribution: ubuntu
    version: "21.04"
  eventLogger: journald
  hostname: hirsute
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.11.0-37-generic
  linkmode: dynamic
  memFree: 205688832
  memTotal: 562302976
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 1.1.5-7b4a-dirty
      commit: 7b4a7042370eea7fb00d3a4da34332b26f080acd
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    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: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.1
  swapFree: 0
  swapTotal: 0
  uptime: 39h 37m 8.59s (Approximately 1.62 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/ubuntu/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.10.2
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.2
        using FUSE kernel interface version 7.31
  graphRoot: /home/ubuntu/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/ubuntu/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 0
  BuiltTime: Wed Dec 31 18:00:00 1969
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.1

Package info (e.g. output of rpm -q podman or apt list podman):

Podman version installed via the Kubic project.

$ apt list podman
Listing... Done
podman/unknown,now 100:3.3.1-1 amd64 [installed]
podman/unknown 100:3.3.1-1 arm64
podman/unknown 100:3.3.1-1 armhf
podman/unknown 100:3.3.1-1 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

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

Host is Ubuntu 21.04 running in Hyper-V VM using multipass

The text was updated successfully, but these errors were encountered:

giuseppe · 2021-10-12T10:14:00Z

the mapping --uidmap=1001:0:1 doesn't specify root in the user namespace.

You need to add at least two IDs, e.g. `--uidmap=1001:0:1 --uidmap=0:1:1

merusso · 2021-10-12T13:55:39Z

@giuseppe, the command above still fails when adding --uidmap=0:1:1:

$ podman run --user 1001 --uidmap=1001:0:1 --uidmap=0:1:1 docker.io/library/ubuntu:focal
Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

Adding --uidmap=0:1:1000 does work. IMO, this is surprising behavior. Prior bug reports like #6123 have mentioned challenges running this command.

Would it be wise for Podman to resolve this automatically without requiring users to explicitly remap container UID 0?
Or at least, should the Podman run documentation be updated?

giuseppe · 2021-10-12T14:48:21Z

ok sorry, didn't understand you want to run with just one user mapped in.

In this case, Podman also adds the same mappings for GIDs if not overriden.

Can you try with:

podman run --sysctl net.ipv4.ping_group_range="1001 1001" --user 1001:1001 --uidmap=1001:0:1 docker.io/library/ubuntu:focal

merusso · 2021-10-12T18:40:53Z

I get the error:

Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

$ podman run --sysctl net.ipv4.ping_group_range="1001 1001" --user 1001:1001 --uidmap=1001:0:1 docker.io/library/ubuntu:focal
Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

This error is now the same as when I run the original command.

$ podman run --user 1001 --uidmap=1001:0:1 docker.io/library/ubuntu:focal
Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

I'm not sure why I can't reproduce the original error now. Perhaps I needed to run a podman system reset after upgrading it or something.

giuseppe · 2021-10-13T07:13:33Z

when you run with a single mapping you also need to specify ignore_chown_errors = "true" in the storage.conf file

merusso · 2021-10-14T05:40:21Z

Unfortunately I still get the same error after adding the following:

~/.config/containers/storage.conf:

[storage]
driver = "overlay"

[storage.options.overlay]
ignore_chown_errors = "true"

...or if I add the argument --storage-opt='ignore_chown_errors=true'

rhatdan · 2021-10-14T10:33:44Z

If you have only one UID available within your user namespace then inside of the user namespace that UID has to be root (I believe) and your process has to run as root.

Could you try without the --user option.

giuseppe · 2021-10-14T14:04:48Z

I think that error is happening at pull time.

If you have only one UID available within your user namespace then inside of the user namespace that UID has to be root (I believe) and your process has to run as root.

crun allows to run with just one user that is not mapped to root.

The last error is happening when creating a copy of the image. I wonder if I didn't see it because I've started with a fresh storage

rhatdan · 2021-10-14T14:18:27Z

Yes this is happening when the image is being downloaded into storage.

rhatdan · 2021-10-14T14:19:07Z

$ podman --root /tmp/storage --storage-opt='overlay.ignore_chown_errors=true' run --uidmap=3267:0:1 docker.io/library/ubuntu:focal
Trying to pull docker.io/library/ubuntu:focal...
Getting image source signatures
Copying blob f3ef4ff62e0d done  
Error: writing blob: adding layer with blob "sha256:f3ef4ff62e0da0ef761ec1c8a578f3035bef51043e53ae1b13a20b3e03726d17": Error processing tar file(exit status 1): Container ID 42 cannot be mapped to a host ID

merusso · 2021-10-15T05:17:57Z

From my experience, the error still happens after a successful pull. I can pull the image separately but get the above errors when trying to run it with --uidmap.

More tests as @rhatdan requested:

With --uidmap but without --user:

$ podman run --uidmap=1001:0:1 docker.io/library/ubuntu:focal echo success
Error: error creating container storage: error creating an ID-mapped copy of layer "da55b45d310bb8096103c29ff01038a6d6af74e14e3b67d1cd488c3ab03f5f0d": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:0, GID:42} for "etc/gshadow" to host: Container ID 42 cannot be mapped to a host ID

Without --uidmap or --user:

$ podman run docker.io/library/ubuntu:focal echo success
success

With --user and 2 --uidmaps:

$ podman run --user 1001 --uidmap=1001:0:1 --uidmap=0:1:1000 docker.io/library/ubuntu:focal echo success
success

giuseppe · 2021-10-15T07:50:25Z

so overlay.ignore_chown_errors=true has an effect only when the user has no additional IDs so every pulled image is squashed to use the same UID/GID for every file.

In the case above, the user has multiple IDs available so the image was pulled without squashing the IDs in the image.

I think we should treat it as an error, since the image uses IDs that are not made available in the user namespace and require the usage of podman run --user 1001 --uidmap=1001:0:1 --uidmap=0:1:1000 docker.io/library/ubuntu:focal echo success

merusso · 2021-10-16T03:16:06Z

Thank you both for taking a look at this.

So do you consider this "working as designed"? I personally found it tricky to use the right command to make this work, since the documentation only mentions podman run --uidmap $container_uid:0:1 --user $container_uid.

zjxpsetp · 2022-11-08T16:45:09Z

any progress？I still find the same problem with podman 4.1.1.

And I found a strange problem, there is no problem when I set uidmap 0:1:1000, but have problem when I set 0:2:1000, it seems that I can not consume more than 1000 subuid in rootless mode ?

openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Oct 11, 2021

giuseppe closed this as completed Oct 12, 2021

rhatdan reopened this Oct 14, 2021

giuseppe closed this as completed Oct 15, 2021

yogo1212 mentioned this issue Sep 26, 2022

setting net.ipv4.ping_group_range fails (uidmap/gidmap) #15934

Closed

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 10, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 10, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error running Podman with --uidmap to non-root container user #11922

Error running Podman with --uidmap to non-root container user #11922

merusso commented Oct 11, 2021 •

edited

giuseppe commented Oct 12, 2021

merusso commented Oct 12, 2021

giuseppe commented Oct 12, 2021

merusso commented Oct 12, 2021

giuseppe commented Oct 13, 2021

merusso commented Oct 14, 2021

rhatdan commented Oct 14, 2021

giuseppe commented Oct 14, 2021

rhatdan commented Oct 14, 2021

rhatdan commented Oct 14, 2021

merusso commented Oct 15, 2021

giuseppe commented Oct 15, 2021

merusso commented Oct 16, 2021

zjxpsetp commented Nov 8, 2022

Error running Podman with --uidmap to non-root container user #11922

Error running Podman with --uidmap to non-root container user #11922

Comments

merusso commented Oct 11, 2021 • edited

giuseppe commented Oct 12, 2021

merusso commented Oct 12, 2021

giuseppe commented Oct 12, 2021

merusso commented Oct 12, 2021

giuseppe commented Oct 13, 2021

merusso commented Oct 14, 2021

rhatdan commented Oct 14, 2021

giuseppe commented Oct 14, 2021

rhatdan commented Oct 14, 2021

rhatdan commented Oct 14, 2021

merusso commented Oct 15, 2021

giuseppe commented Oct 15, 2021

merusso commented Oct 16, 2021

zjxpsetp commented Nov 8, 2022

merusso commented Oct 11, 2021 •

edited