Inspect Linux Process Capabilities with getpcaps

You will inspect the capabilities attached to a running Linux process, compare the normal and legacy display formats, and recognise the errors caused by a missing process. Allow about ten minutes. You need the getpcaps program and a process ID that you are allowed to inspect. The examples are read-only and normally do not need sudo.

1. Check the installed command

Start by confirming which executable your shell will run:

$ command -v getpcaps
/home/linuxbrew/.linuxbrew/sbin/getpcaps
$ dpkg-query -W -f='${binary:Package} ${Version}\n' libcap2-bin
libcap2-bin 1:2.66-5ubuntu2.4

The package metadata on this machine reports libcap2-bin 1:2.66-5ubuntu2.4. The executable is supplied by the local libcap installation, so use command -v when you need to establish the exact binary being tested. The installed help text is also a useful contract check:

$ getpcaps --help
usage: getpcaps [opts] <pid> [pid ...]

This program displays the capabilities on the queried process(es).

Checkpoint: you should have a real path for getpcaps and a help message that accepts one or more process IDs. If another copy appears first in PATH, resolve that before comparing results with this guide.

2. Inspect your current shell

The shell's process ID is available as $$. Pass it as an ordinary, unprivileged query:

$ getpcaps $$
3456888: =

Your number will differ. The output uses the process ID followed by a capability set in the text notation used by cap_from_text(3). An equals sign with no named capabilities means that this process has no capabilities displayed in that set. Do not read the example PID as a value to copy into another shell.

For a process ID stored in a variable, quote the variable and keep it as one argument:

$ TARGET_PID=$$
$ getpcaps "$TARGET_PID"
3456888: =

Use a real numeric PID in automation. Avoid accepting an arbitrary option string from another user and appending it to this command, because a diagnostic tool should not become an unintended command interface.

3. Use PID 0 for the getpcaps process

A PID of 0 is a documented special case. It asks getpcaps to display the capabilities of the process running getpcaps itself:

$ getpcaps 0
0: =

This is not the same as querying the shell with $$. It is useful for a quick smoke test because it does not require you to discover another process first. The label remains 0 in the output, even though the program is inspecting its own process.

Checkpoint: compare getpcaps 0 with getpcaps $$. Similar capability text is plausible, but the two commands refer to different processes.

4. Query several processes in one command

Place multiple numeric PIDs after the options. The output contains one result per process:

$ getpcaps 0 $$
0: =
3456888: =

This is handy when checking a launcher and its child, or when comparing a service process with a diagnostic shell. The command only reports the processes that exist at query time. A process can exit between discovering its PID and running getpcaps, so an intermittent failure does not prove that the capability configuration changed.

5. Choose a display format

The default is the compact form. --verbose adds a label that is easier to read in a terminal:

$ getpcaps --verbose $$
Capabilities for '3456888': =

--legacy and --ugly select the older format. They are useful when comparing output with an existing script or an older operational record:

$ getpcaps --legacy $$
Capabilities for `3456888': =

For scripts, choose one format deliberately and parse only the format you have tested. Human-readable output can change between libcap releases, while the process ID and capability notation are the useful facts to preserve in a report.

6. Try the IAB view only when you need it

The --iab option asks for the process capabilities together with its inheritable, ambient and bounding information in the IAB text format. The exact result depends on the process and libcap build:

$ getpcaps --iab $$
3456888:

Do not assume that an empty-looking IAB portion means the process is broken. It can simply mean that there are no IAB entries to print. If you need a detailed interpretation, compare the result with the capability policy that launched the process and with the installed cap_iab(3) documentation.

7. Diagnose a failed lookup

A nonexistent or already-exited PID produces an error and a non-zero status:

$ getpcaps 999999
Failed to get cap's for process 999999: (No such process)
$ printf 'exit status: %s\n' "$?"
exit status: 1

Use a current process list to find a replacement PID, then retry:

$ pgrep -x YOUR_PROCESS_NAME
1234
$ getpcaps 1234

Replace YOUR_PROCESS_NAME with an exact executable name. If the process belongs to another user or is protected by the host's access controls, retrying with sudo may be necessary, but elevation changes the process doing the inspection and should be recorded in the diagnostic notes. Do not use sudo merely because the command is about security.