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 play kube ignores USER (rootless) #9609

Closed
ghost opened this issue Mar 4, 2021 · 6 comments · Fixed by #10383
Closed

Podman play kube ignores USER (rootless) #9609

ghost opened this issue Mar 4, 2021 · 6 comments · Fixed by #10383
Assignees
Labels
Good First Issue This issue would be a good issue for a first time contributor to undertake. In Progress This issue is actively being worked by the assignee, please do not work on this at this time. 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 Mar 4, 2021

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

/kind bug

Description

The podman play kube command does not use the user specified in the Dockerfile

Steps to reproduce the issue:

  1. Build simple image with USER step:
FROM docker.io/centos

RUN useradd -c 'testuser' -m -p '!' -u 10000 -s '/bin/bash' testuser

USER testuser

CMD tail -f /dev/null
  1. Write yaml file that uses this image:
---

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: pod
  name: pod
spec:
  containers:
  - name: nginx
    image: localhost/testimage
    env:
     - name: SOME_ENV
       value: "VALUE"
    ports:
    - containerPort: 111111
      hostPort: 11111
      protocol: TCP
    volumeMounts:
    - mountPath: /home/podman/testdir
      name:  testdir

  volumes:
  - name: testdir
    hostPath:
      path: /home/podman/testdir
      type: Directory
  1. Play the file: podman play kube test.yaml
  2. Check who is the user in the running container:
podman exec pod-nginx whoami
root
  1. Run the same image without podman play kube:
podman run -ti localhost/testimage whoami
testuser

Describe the results you received:
The user should be the same ("testuser" in this case) with or without podman play kube.

Describe the results you expected:
The user is "root" when I use podman play kube.

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

Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.14.12
Built:        Mon Mar  1 15:31:01 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.4
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.26-4.el8.5.1.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: c30e47104fbc00a7381abe56ad8d54ab151f3fde'
  cpus: 4
  distribution:
    distribution: '"centos"'
    version: "8"
  eventLogger: journald
  hostname: mymachine
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 795
      size: 1
    - container_id: 1
      host_id: 100000
      size: 10001
    uidmap:
    - container_id: 0
      host_id: 988
      size: 1
    - container_id: 1
      host_id: 100000
      size: 10001
  kernel: 4.18.0-240.10.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 6644281344
  memTotal: 8346820608
  ociRuntime:
    name: crun
    package: crun-0.18-3.el8.5.1.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.18
      commit: 808420efe3dc2b44d6db9f1a3fac8361dde42a95
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-988/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
    selinuxEnabled: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-4.el8.7.1.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 2143285248
  swapTotal: 2147479552
  uptime: 22h 59m 3.58s (Approximately 0.92 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 2
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-3.el8.4.1.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.4
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/podman/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 10
  runRoot: /tmp/podman-run-988/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1614609061
  BuiltTime: Mon Mar  1 15:31:01 2021
  GitCommit: ""
  GoVersion: go1.14.12
  OsArch: linux/amd64
  Version: 3.0.1

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

podman-3.0.1-2.el8.3.1.x86_64

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

Yes

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 4, 2021
@x70b1
Copy link

x70b1 commented Mar 4, 2021

I can confirm this. I have found the same issue in podman version 3.0.1 on Debian 10.

Running an image with USER defined in the Containerfile with podman run imagename runs the process as root.
But podman run -u username imagename works fine.

@mheon
Copy link
Member

mheon commented Mar 17, 2021

I'll take this one.

@mheon mheon self-assigned this Mar 17, 2021
@github-actions
Copy link

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

@rhatdan
Copy link
Member

rhatdan commented Apr 17, 2021

@mheon did you ever get a chance to work on thisone?

@rhatdan rhatdan added Good First Issue This issue would be a good issue for a first time contributor to undertake. and removed stale-issue labels Apr 17, 2021
@mheon
Copy link
Member

mheon commented Apr 17, 2021 via email

@github-actions
Copy link

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

rhatdan added a commit to rhatdan/podman that referenced this issue May 18, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@rhatdan rhatdan assigned rhatdan and unassigned mheon May 18, 2021
rhatdan added a commit to rhatdan/podman that referenced this issue May 18, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 18, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 18, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 20, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 20, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 24, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 25, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@baude baude added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label May 25, 2021
rhatdan added a commit to rhatdan/podman that referenced this issue May 26, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rugk pushed a commit to rugk/podman that referenced this issue Jul 9, 2021
Currently if a user runs an image with a user specified or
exposed ports with podman play kube, the fields are ignored.

Fixed: containers#9609

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
zaneb added a commit to zaneb/fleeting that referenced this issue Feb 28, 2022
Work around containers/podman#9609 (which causes the USER set in the
Dockerfile to be ignored) in Podman 3.2.3.
(The issue is fixed in Podman 3.3.)

Co-authored-by: Richard Su <rwsu@redhat.com>
zaneb added a commit to zaneb/openshift-installer that referenced this issue Apr 26, 2022
Work around containers/podman#9609 (which causes the USER set in the
Dockerfile to be ignored) in Podman 3.2.3.
(The issue is fixed in Podman 3.3.)

Co-authored-by: Richard Su <rwsu@redhat.com>
zaneb added a commit to zaneb/openshift-installer that referenced this issue Apr 29, 2022
Work around containers/podman#9609 (which causes the USER set in the
Dockerfile to be ignored) in Podman 3.2.3.
(The issue is fixed in Podman 3.3.)

Co-authored-by: Richard Su <rwsu@redhat.com>
lranjbar pushed a commit to lranjbar/installer that referenced this issue May 28, 2022
Work around containers/podman#9609 (which causes the USER set in the
Dockerfile to be ignored) in Podman 3.2.3.
(The issue is fixed in Podman 3.3.)

Co-authored-by: Richard Su <rwsu@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
Good First Issue This issue would be a good issue for a first time contributor to undertake. In Progress This issue is actively being worked by the assignee, please do not work on this at this time. 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.

5 participants