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

Podman rootless container with --uidmap and --pod cannot bind to ports below 1024 #12669

Closed
lackhove opened this issue Dec 21, 2021 · 7 comments · Fixed by #12849
Closed

Podman rootless container with --uidmap and --pod cannot bind to ports below 1024 #12669

lackhove opened this issue Dec 21, 2021 · 7 comments · Fixed by #12849
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

@lackhove
Copy link

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

/kind bug

Description

When using --uidmap and --pod on a rootless container, the container cannot bind to port 80.

Steps to reproduce the issue:

  1. Create a rootless pod
podman pod create --name testpod --hostname testpod  -p 8080:80
  1. Create a container which listens to port 80 in that pod:
$ podman run -it --rm  --pod=testpod  docker.io/traefik/whoami                                                                                                                                            
2021/12/21 11:53:27 Starting up on port 80
  1. Stop/Remove that container and create a new one with --uidmap:
$ podman run -it --rm  --pod=testpod   --uidmap=0:0:1000 docker.io/traefik/whoami                                                                                                                           
2021/12/21 11:47:22 Starting up on port 80
2021/12/21 11:47:22 listen tcp :80: bind: permission denied

and see it fail.

  1. Run the container with a port >= 1024:
 $ podman run -it --rm  --pod=testpod   --uidmap=0:0:1000 docker.io/traefik/whoami --port=1024                                                                                                               
2021/12/21 12:06:53 Starting up on port 1024

Describe the results you received:

The container is not able to bind to port 80

Describe the results you expected:

The container is able to bind to port 80

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

Issue happens on my fedora core OS box with SELinux and on my arch notebook without SELinux. sudo sysctl net.ipv4.ip_unprivileged_port_start=30 does not help either. The problem persists with other images (tested with nextcloud)

Output of podman version:

Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.17.3
Git Commit:   2ad1fd3555de12de34e20898cc2ef901f08fe5ed
Built:        Fri Nov 12 22:41:08 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon ist in conmon 1:2.0.30-1 enthalten
    path: /usr/bin/conmon
    version: 'conmon version 2.0.30, commit: 2792c16f4436f1887a7070d9ad99d9c29742f38a'
  cpus: 4
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  hostname: kilian-xps13
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 100000
      size: 100000
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 100000
  kernel: 5.15.5-arch1-1
  linkmode: dynamic
  logDriver: journald
  memFree: 3607879680
  memTotal: 8050868224
  ociRuntime:
    name: crun
    package: /usr/bin/crun ist in crun 1.3-1 enthalten
    path: /usr/bin/crun
    version: |-
      crun version 1.3
      commit: 4f6c8e0583c679bfee6a899c05ac6b916022561b
      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: 9446825984
  swapTotal: 9446825984
  uptime: 1h 34m 37.12s (Approximately 0.04 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/kilian/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/kilian/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/kilian/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.2
  Built: 1636753268
  BuiltTime: Fri Nov 12 22:41:08 2021
  GitCommit: 2ad1fd3555de12de34e20898cc2ef901f08fe5ed
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.2

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

$ yay -Qi podman
Name                     : podman
Version                  : 3.4.2-1
Beschreibung             : Tool and library for running OCI-based containers in pods
Architektur              : x86_64
URL                      : https://github.com/containers/podman
Lizenzen                 : Apache
Gruppen                  : Nichts
Stellt bereit            : Nichts
Hängt ab von             : cni-plugins  conmon  containers-common  crun  fuse-overlayfs  iptables  libdevmapper.so=1.02-64  libgpgme.so=11-64  libseccomp.so=2-64  slirp4netns
Optionale Abhängigkeiten : apparmor: for AppArmor support
                           btrfs-progs: support btrfs backend devices [Installiert]
                           catatonit: --init flag support
                           podman-docker: for Docker-compatible CLI
Benötigt von             : toolbox
Optional für             : Nichts
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
Installationsgröße       : 72,73 MiB
Packer                   : Morten Linderud <foxboron@archlinux.org>
Erstellt am              : Fr 12 Nov 2021 22:41:08 CET
Installiert am           : Di 30 Nov 2021 21:01:58 CET
Installationsgrund       : Installiert als Abhängigkeit eines anderen Pakets
Installations-Skript     : Nein
Verifiziert durch        : Signatur

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, Yes

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

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

rhatdan commented Dec 21, 2021

In the latest branch, I believe specifying a UIDmap different then the pod you are joining, is not allowed.

Basically --uidmap and --pod should conflict, if you want to create a pod in a particular UserNS mapping, then you need to do it at Pod Creation. All containers of a POD have to run within the PODs user namespace. (At least if they are sharing the userns.

@rhatdan
Copy link
Member

rhatdan commented Dec 21, 2021

@cdoern Am I correct in assuming these conflict?

@cdoern
Copy link
Contributor

cdoern commented Dec 21, 2021

Yes, I think that conflict is supposed to happen. You should be able to resolve this by setting --share=none then the containers do not share the UserNS w/ the pod. The issue here is that when sharing with the pod you are really sharing with the infra container. So setting a new uidmap that goes against infra's userNS setup is not allowed. @mheon can you confirm that this makes sense?

@mheon
Copy link
Member

mheon commented Dec 22, 2021

Yes, that's accurate - the two options should be mutually-exclusive assuming that any namespaces are shared by the pod.

@lackhove
Copy link
Author

Thank you für the quick reply. I now usw --uidmap on the pod and it works as expected. Do you want me to keep this issue open as a reminder to have --pod and --uidmap conflicting?

@rhatdan
Copy link
Member

rhatdan commented Jan 13, 2022

Yes, @cdoern Can you open a PR to stop --uidman/--gidmap on the client if you are in a Pod.

@cdoern
Copy link
Contributor

cdoern commented Jan 13, 2022

Sure @rhatdan, I'll just put it at the cmd level

cdoern added a commit to cdoern/podman that referenced this issue Jan 13, 2022
add a check in namespaceOptions() that ensures the user is not setting a new uid/gid map
if entering or creating a pod that has an infra container

resolves containers#12669

Signed-off-by: cdoern <cdoern@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.

4 participants