mirror of
https://github.com/containers/podman.git
synced 2025-08-06 03:19:52 +08:00
597ebeb60f
This ended up more complicated then expected. Lets start first with the problem to show why I am doing this: Currently we simply execute ps(1) in the container. This has some drawbacks. First, obviously you need to have ps(1) in the container image. That is no always the case especially in small images. Second, even if you do it will often be only busybox's ps which supports far less options. Now we also have psgo which is used by default but that only supports a small subset of ps(1) options. Implementing all options there is way to much work. Docker on the other hand executes ps(1) directly on the host and tries to filter pids with `-q` an option which is not supported by busybox's ps and conflicts with other ps(1) arguments. That means they fall back to full ps(1) on the host and then filter based on the pid in the output. This is kinda ugly and fails short because users can modify the ps output and it may not even include the pid in the output which causes an error. So every solution has a different drawback, but what if we can combine them somehow?! This commit tries exactly that. We use ps(1) from the host and execute that in the container's pid namespace. There are some security concerns that must be addressed: - mount the executable paths for ps and podman itself readonly to prevent the container from overwriting it via /proc/self/exe. - set NO_NEW_PRIVS, SET_DUMPABLE and PDEATHSIG - close all non std fds to prevent leaking files in that the caller had open - unset all environment variables to not leak any into the contianer Technically this could be a breaking change if somebody does not have ps on the host and only in the container but I find that very unlikely, we still have the exec in container fallback. Because this can be insecure when the contianer has CAP_SYS_PTRACE we still only use the podman exec version in that case. This updates the docs accordingly, note that podman pod top never falls back to executing ps in the container as this makes no sense with multiple containers so I fixed the docs there as well. Fixes #19001 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2215572 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
115 lines
3.5 KiB
Markdown
115 lines
3.5 KiB
Markdown
% podman-top 1
|
|
|
|
## NAME
|
|
podman\-top - Display the running processes of a container
|
|
|
|
## SYNOPSIS
|
|
**podman top** [*options*] *container* [*format-descriptors*]
|
|
|
|
**podman container top** [*options*] *container* [*format-descriptors*]
|
|
|
|
## DESCRIPTION
|
|
Display the running processes of the container. The *format-descriptors* are ps (1) compatible AIX format
|
|
descriptors but extended to print additional information, such as the seccomp mode or the effective capabilities
|
|
of a given process. The descriptors can either be passed as separated arguments or as a single comma-separated
|
|
argument. 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.
|
|
Please use the "h*" descriptors to extract host-related information. For instance, `podman top $name hpid huser`
|
|
to display the PID and user of the processes in the host context.
|
|
|
|
## OPTIONS
|
|
|
|
#### **--help**, **-h**
|
|
|
|
Print usage statement
|
|
|
|
@@option latest
|
|
|
|
## FORMAT DESCRIPTORS
|
|
|
|
The following descriptors are supported in addition to the AIX format descriptors mentioned in ps (1):
|
|
|
|
**args, capbnd, capeff, capinh, capprm, comm, etime, group, hgroup, hpid, huser, label, nice, pcpu, pgid, pid, ppid, rgroup, ruser, seccomp, state, time, tty, user, vsz**
|
|
|
|
**capbnd**
|
|
|
|
Set of bounding capabilities. See capabilities (7) for more information.
|
|
|
|
**capeff**
|
|
|
|
Set of effective capabilities. See capabilities (7) for more information.
|
|
|
|
**capinh**
|
|
|
|
Set of inheritable capabilities. See capabilities (7) for more information.
|
|
|
|
**capprm**
|
|
|
|
Set of permitted capabilities. See capabilities (7) for more information.
|
|
|
|
**hgroup**
|
|
|
|
The corresponding effective group of a container process on the host.
|
|
|
|
**hpid**
|
|
|
|
The corresponding host PID of a container process.
|
|
|
|
**huser**
|
|
|
|
The corresponding effective user of a container process on the host.
|
|
|
|
**label**
|
|
|
|
Current security attributes of the process.
|
|
|
|
**seccomp**
|
|
|
|
Seccomp mode of the process (i.e., disabled, strict or filter). See seccomp (2) for more information.
|
|
|
|
**state**
|
|
|
|
Process state codes (e.g, **R** for *running*, **S** for *sleeping*). See proc(5) for more information.
|
|
|
|
**stime**
|
|
|
|
Process start time (e.g, "2019-12-09 10:50:36 +0100 CET).
|
|
|
|
## EXAMPLES
|
|
|
|
By default, `podman-top` prints data similar to `ps -ef`:
|
|
|
|
```
|
|
$ podman top f5a62a71b07
|
|
USER PID PPID %CPU ELAPSED TTY TIME COMMAND
|
|
root 1 0 0.000 20.386825206s pts/0 0s sh
|
|
root 7 1 0.000 16.386882887s pts/0 0s sleep
|
|
root 8 1 0.000 11.386886562s pts/0 0s vi
|
|
```
|
|
|
|
The output can be controlled by specifying format descriptors as arguments after the container:
|
|
|
|
```
|
|
$ podman top -l pid seccomp args %C
|
|
PID SECCOMP COMMAND %CPU
|
|
1 filter sh 0.000
|
|
8 filter vi /etc/ 0.000
|
|
```
|
|
|
|
Podman falls back to executing ps(1) from the host in the container namespace if an unknown descriptor is specified.
|
|
|
|
```
|
|
$ podman top -l -- aux
|
|
USER PID PPID %CPU ELAPSED TTY TIME COMMAND
|
|
root 1 0 0.000 1h2m12.497061672s ? 0s sleep 100000
|
|
```
|
|
|
|
## SEE ALSO
|
|
**[podman(1)](podman.1.md)**, **ps(1)**, **seccomp(2)**, **proc(5)**, **capabilities(7)**
|
|
|
|
## HISTORY
|
|
July 2018, Introduce format descriptors by Valentin Rothberg <vrothberg@suse.com>
|
|
|
|
December 2017, Originally compiled by Brent Baude <bbaude@redhat.com>
|