command sudo cannot work in podman container

[LittFlower]

Issue Description

Hello everyone. I have a podman container which was created by ubuntu:22.04 image. A bug occurred after a certain kernel update. There was a problem with the file permissions in my container. Specifically, when I used podman run --it -v /home/flower/CTFhub:/home/flower/CTFhub:rw --group-add $(getent group flower | cut -d: -f3) --userns keep-id -u $(id -u flower):$(id -g flower) littflower/dockerpwn:v6 bash to create a container and attached it, I got:

The attach command looks like this:

you can find my image here

thanks for your help.

Steps to reproduce the issue

Steps to reproduce the issue

1. podman run --it -v /home/flower/CTFhub:/home/flower/CTFhub:rw --group-add $(getent group flower | cut -d: -f3) --userns keep-id -u $(id -u flower):$(id -g flower) littflower/dockerpwn:v6 bash
2. su -

Describe the results you received

just like these:

Describe the results you expected

I thought when I type sudo it should work fine and give me superuser rights.

podman info output

The following is my system configuration information:


$ podman version
Client:       Podman Engine
Version:      5.0.2
API Version:  5.0.2
Go Version:   go1.22.2
Git Commit:   3304dd95b8978a8346b96b7d43134990609b3b29-dirty
Built:        Thu Apr 18 19:13:19 2024
OS/Arch:      linux/amd64

$ podman info
host:
  arch: amd64
  buildahVersion: 1.35.3
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon 由 conmon 1:2.1.10-1 所拥有
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: 2dcd736e46ded79a53339462bc251694b150f870'
  cpuUtilization:
    idlePercent: 95.44
    systemPercent: 0.75
    userPercent: 3.81
  cpus: 20
  databaseBackend: sqlite
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  freeLocks: 2030
  hostname: ArchLinux
  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: 6.8.7-arch1-1.1-g14
  linkmode: dynamic
  logDriver: journald
  memFree: 5492482048
  memTotal: 16377323520
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: Unknown
    package: /usr/lib/podman/netavark 由 netavark 1.10.3-1 所拥有
    path: /usr/lib/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: /usr/bin/crun 由 crun 1.14.4-2 所拥有
    path: /usr/bin/crun
    version: |-
      crun version 1.14.4
      commit: a220ca661ce078f2c37b38c92e66cf66c012d9c1
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: /usr/bin/pasta 由 passt 2024_04_26.d03c4e2-1 所拥有
    version: |
      pasta 2024_04_26.d03c4e2
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: false
    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 由 slirp4netns 1.3.0-1 所拥有
    version: |-
      slirp4netns version 1.3.0
      commit: 8a4d4391842f00b9c940bb8f067964427eb0c964
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.5
  swapFree: 8579969024
  swapTotal: 8589930496
  uptime: 4h 60m 48.00s (Approximately 0.17 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /home/flower/.config/containers/storage.conf
  containerStore:
    number: 18
    paused: 0
    running: 2
    stopped: 16
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/flower/.local/share/containers/storage
  graphRootAllocated: 923336273920
  graphRootUsed: 390578380800
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 9
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/flower/.local/share/containers/storage/volumes
version:
  APIVersion: 5.0.2
  Built: 1713438799
  BuiltTime: Thu Apr 18 19:13:19 2024
  GitCommit: 3304dd95b8978a8346b96b7d43134990609b3b29-dirty
  GoVersion: go1.22.2
  Os: linux
  OsArch: linux/amd64
  Version: 5.0.2

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional information

The cause of this problem may be that I did not restart the system immediately after updating the kernel, which caused unexpected things to happen to the container.

[Luap99]

Did you check the file permissions on the sudo binary? Is the underlying file system mounted nosuid maybe, etc...
Also please do not provide sceenshots of terminal text, always copy and paste it which makes it much more readable.

In any case I don't see how this is podman bug so I move it to a discussion

[LittFlower]

fine. that is my problem. thank you for your help

[nalind]

We don't have access to the image in question, and I don't have a guess for how the container's /usr/bin/sudo lost its setuid bit, but I'd suggest using something like podman exec -it --user root to start a shell in the container from a different terminal after it's been started, and using apt-get reinstall sudo util-linux to repair the permissions on the binaries.