Inspect Linux Process Capabilities with getpcaps

getpcaps prints the Linux capabilities attached to a running process, in either the modern or legacy text notation. You will compare both display formats and learn to recognise the errors a missing process produces. Allow about ten minutes.

You need the getpcaps program and a process ID 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 actually 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 comes from the local libcap installation, so use command -v whenever you need to pin down the exact binary being tested. The installed help text doubles as a quick contract check:

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

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

2. Inspect Your Current Shell

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

$ getpcaps $$
3456888: =

Your number will differ. The output is the process ID followed by a capability set in the text notation used by cap_from_text(3). An equals sign with nothing named after it means this process has no capabilities in that set. Do not copy the example PID into another shell and expect it to mean anything there.

For a PID stored in a variable, quote it and keep it as one argument:

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

Use a real numeric PID in automation, and avoid accepting an arbitrary option string from another user and appending it here: a diagnostic tool should not double as an unintended command interface.

3. Use PID 0 for the getpcaps Process Itself

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

$ getpcaps 0
0: =

That is not the same process as the shell you queried with $$. It is a handy smoke test precisely because it does not require you to find another process first. The output label stays 0, even though the program is inspecting its own process.

4. Query Several Processes at Once

Put multiple numeric PIDs after the options. You get one result line per process:

$ getpcaps 0 $$
0: =
3456888: =

Handy for checking a launcher against its child, or comparing a service process with a diagnostic shell. The command only reports processes that exist at query time: a process can exit between you discovering its PID and running getpcaps, so an intermittent failure does not by itself prove the capability configuration changed.

5. Choose a Display Format

The default is compact. --verbose adds a label that reads more easily in a terminal:

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

--legacy and --ugly select the older format, useful when comparing output against an existing script or an older operational record:

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

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 the libcap build:

$ getpcaps --iab $$
3456888:

Do not assume an empty-looking IAB portion means the process is broken; it can simply mean there are no IAB entries to print. For 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

Find a live PID and 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 note in your diagnostic notes that elevation changes which process is doing the inspecting. Do not reach for sudo just because the command is about security.