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

rootless podman run --network=none from inside a container due to default_sysctls ping_group_range #13194

Closed
bburky opened this issue Feb 9, 2022 · 4 comments
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

@bburky
Copy link

bburky commented Feb 9, 2022

Description

Inside a container /proc/sys/net/ipv4/ping_group_range may not exist. The default_sysctls include net.ipv4.ping_group_range=0 0. If rootless podman is run inside a container, accessing this file may fail.

I discovered this when trying to run a rootless podman run --network=none ... inside a Kubernetes container.

Steps to reproduce the issue:

To reproduce the issue, run the following command which fails with Error: OCI runtime error: open /proc/sys/net/ipv4/ping_group_range: Read-only file system:

podman run --rm -it \
    --security-opt=label=disable \
    --security-opt=seccomp=unconfined \
    --env STORAGE_DRIVER=vfs \
    --user=podman \
    quay.io/podman/stable:v3.4.4 \
        podman run --rm -it --network=none alpine

A workaround is editing ~/.config/containers/containers.conf inside the container to not include net.ipv4.ping_group_range:

[containers]
volumes = [
	"/proc:/proc",
]
default_sysctls = []

Describe the results you received:

Error: OCI runtime error: open /proc/sys/net/ipv4/ping_group_range: Read-only file system

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

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.16.8
Built:        Wed Dec  8 21:45:07 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

podman info --debug
host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpus: 1
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: 0258298c13b6
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 5000
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 5000
  kernel: 5.15.17-200.fc35.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 543858688
  memTotal: 2061381632
  ociRuntime:
    name: crun
    package: crun-1.4.2-1.fc35.x86_64
    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: /tmp/podman-run-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-1.1.12-2.fc35.x86_64
    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: 25m 43.5s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/podman/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 1
  runRoot: /tmp/podman-run-1000/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 1638999907
  BuiltTime: Wed Dec  8 21:45:07 2021
  GitCommit: ""
  GoVersion: go1.16.8
  OsArch: linux/amd64
  Version: 3.4.4

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

podman-3.4.4-1.fc35.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

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

Rootless podman running inside a containerized environment without /proc/sys/net/ipv4/ping_group_range

This is mostly a duplicate of #8482, but for --network=none this time. 0d70df1 fixed this only for --network=host. Adding a check for network=none in specgen/generate/security.go may fix this?

/kind bug

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 9, 2022
@rhatdan
Copy link
Member

rhatdan commented Feb 10, 2022

I am not sure what you want Podman to fix here. Are you looking at quay.io/podman/stable?

@bburky
Copy link
Author

bburky commented Feb 11, 2022

Basically the same as #8482, which updated podman to not set sysctls when rootless --network=host is set. Similarly, don't set sysctls when rootless --network=none.

giuseppe added a commit to giuseppe/libpod that referenced this issue Feb 16, 2022
ignore the network sysctls when --net=none is specified.

Closes: containers#13194

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@giuseppe
Copy link
Member

I think it makes sense. Opened a PR: #13250

@giuseppe
Copy link
Member

since the fix was not accepted, should we close this issue?

@rhatdan rhatdan closed this as completed Feb 17, 2022
@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.

3 participants