podman doesn't use host ps when privileged

[pbjhelmert]

Issue Description

Similar to #8033 and #19001, podman top ... -eo pid,comm fails to execute ps in containers without ps. It seems that this fix was incomplete, and went unfixed in the case of a container created with podman run --privileged.

Like some users in those issues, this execution pattern is inflexible for me as this is being run inside of Jenkins.

Steps to reproduce the issue

Steps to reproduce the issue

 ~/git/podman $ ./bin/podman run --privileged -td rockylinux:10
266fd0e4c2c01115cff67a11c63d702c138264dadd5921894b89a458f98fb9a5
 ~/git/podman $ ./bin/podman top 266fd0e4c2c01115cff67a11c63d702c138264dadd5921894b89a458f98fb9a5 -eo pid,comm
Error: executing ps(1) in container: crun: executable file `ps` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found
 ~/git/podman $ ./bin/podman run -td rockylinux:10
98e48a3a478719a98b062907d215939c25608408da8855633fe9d1f5d15884cb
 ~/git/podman $ ./bin/podman top 98e48a3a478719a98b062907d215939c25608408da8855633fe9d1f5d15884cb -eo pid,comm
    PID COMMAND
      1 bash
      2 ps

Describe the results you received

podman top ... -eo pid,comm fails in privileged containers.

Describe the results you expected

podman top ... -eo pid,comm shouldn't fail in privileged containers.

podman info output

~/git/podman $ ./bin/podman info
host:
  arch: amd64
  buildahVersion: 1.42.0-dev
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: app-containers/conmon-2.1.13
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.1.13, commit: unknown'
  cpuUtilization:
    idlePercent: 96.46
    systemPercent: 0.74
    userPercent: 2.8
  cpus: 20
  databaseBackend: boltdb
  distribution:
    distribution: gentoo
    version: "2.17"
  eventLogger: journald
  freeLocks: 2015
  hostname: ...
  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.12.41-gentoo-dist
  linkmode: dynamic
  logDriver: journald
  memFree: 22157414400
  memTotal: 67001339904
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: app-containers/aardvark-dns-1.14.0
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.14.0
    package: app-containers/netavark-1.14.1
    path: /usr/libexec/podman/netavark
    version: netavark 1.14.1
  ociRuntime:
    name: crun
    package: app-containers/crun-1.20
    path: /usr/bin/crun
    version: |-
      crun version 1.20
      commit: 9c9a76ac11994701dd666c4f0b869ceffb599a66
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: net-misc/passt-2025.04.15
    version: ""
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: app-containers/slirp4netns-1.2.0
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.6.0
  swapFree: 0
  swapTotal: 0
  uptime: 27h 49m 23.00s (Approximately 1.12 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/jhelmert/.config/containers/storage.conf
  containerStore:
    number: 32
    paused: 0
    running: 2
    stopped: 30
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jhelmert/.local/share/containers/storage
  graphRootAllocated: 1023117623296
  graphRootUsed: 619798482944
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 7
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/jhelmert/.local/share/containers/storage/volumes
version:
  APIVersion: 5.7.0-dev
  Built: 1757027946
  BuiltTime: Thu Sep  4 16:19:06 2025
  GitCommit: c24b8f6f56d2c3aa4b17ffc74da78b543fe18883
  GoVersion: go1.24.6
  Os: linux
  OsArch: linux/amd64
  Version: 5.7.0-dev

Podman in a container

No

Privileged Or Rootless

Rootless with --privileged

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

I've also bumped into this on Rocky 9, and tested from bb72016 for good measure (doesn't seem like a regression since then).

[Luap99]

The fix works as documented

https://docs.podman.io/en/latest/markdown/podman-top.1.html

Note that options and or flags of ps(1) can also be specified; in this case, Podman falls back to executing ps(1) from the host with the specified arguments and flags in the container namespace. If the container has the CAP_SYS_PTRACE capability then we will execute ps(1) in the container so it must be installed there.

It is insecure to try to execute host binary in the container context like that and there are chances that this can be exploited so we don't allow that.

[Luap99]

Labelling as feature for now, but I don't think anything around this has changed since then security wise.
cc @giuseppe

[giuseppe]

not sure how much we can really protect the host when a container is running with CAP_SYS_PTRACE (any exec is practically unsafe), but I think we should not make things worse by executing a host process inside the container for top when the container can attack the host ps program.

[github-actions]

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

[Luap99]

Closing as it works a documented