Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

userns = "auto" not respected in containers.conf #12615

Closed
ghost opened this issue Dec 15, 2021 · 1 comment · Fixed by #12621
Closed

userns = "auto" not respected in containers.conf #12615

ghost opened this issue Dec 15, 2021 · 1 comment · Fixed by #12621
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@ghost
Copy link

ghost commented Dec 15, 2021

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

/kind bug

Description

userns = "auto" in /etc/containers/containers.conf does not seem to be respected.

Steps to reproduce the issue:

  1. Add subuid and subgid maps for containers
echo 'containers:200000:6553600' >> /etc/subuid
echo 'containers:200000:6553600' >> /etc/subgid
  1. Set userns = "auto" in containers.conf under [containers] heading

alpine:~# podman run -it --rm alpine cat /proc/self/uid_map
         0          0 4294967295

Describe the results you received:

The container's root is mapped to the hosts's root.
The contents of '/proc/self/uid_map':
0 0 4294967295

Describe the results you expected:

I expect the container's root to be mapped to a uid somewhere in the range set in /etc/subuid

This should yield the same output as if --userns auto is provided in the run command:

alpine:~# podman run -it --rm --userns auto alpine cat /proc/self/uid_map
         0     200000       1024

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

Using the environment variable works the same as using the --userns flag.

alpine:~# PODMAN_USERNS="auto" podman run -it --rm alpine cat /proc/self/uid_map
         0     200000       1024

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.4
Git Commit:   72df58eb05290e506c96069e0c5c8d0afab3041f
Built:        Sat Dec 11 08:04:57 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.30, commit: 6ef8a4d4d76656172a4b7a9d406bfc6c629c20db'
  cpus: 4
  distribution:
    distribution: alpine
    version: 3.15.0
  eventLogger: file
  hostname: alpine
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.5-0-virt
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 7986487296
  memTotal: 8350650368
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 1.3
      commit: 4f6c8e0583c679bfee6a899c05ac6b916022561b
      spec: 1.0.0
      +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/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: false
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 4294963200
  swapTotal: 4294963200
  uptime: 2m 5.63s
plugins:
  log:
  - k8s-file
  - none
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 1639227897
  BuiltTime: Sat Dec 11 08:04:57 2021
  GitCommit: 72df58eb05290e506c96069e0c5c8d0afab3041f
  GoVersion: go1.17.4
  OsArch: linux/amd64
  Version: 3.4.4

Package info (output of apk info podman):

podman-3.4.4-r0 description:
Simple management tool for pods, containers and images

podman-3.4.4-r0 webpage:
https://podman.io/

podman-3.4.4-r0 installed size:
35 MiB

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, I have tested with version 3.4.4 and I checked the guide.

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

The alpine machine this was tested on is a KVM virtual machine, however the same issue was also observed on a baremetal Debian 11 machine with podman 3.0.1

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Dec 15, 2021
@giuseppe giuseppe self-assigned this Dec 16, 2021
@giuseppe
Copy link
Member

PR here: #12621

giuseppe added a commit to giuseppe/libpod that referenced this issue Dec 20, 2021
when using the default userns value, make sure its value is parsed so
that userns=auto is parsed and the options for the storage are filled.

Closes: containers#12615

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@github-actions 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 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant