Audit Linux File Capabilities with getcap

Find out which binaries on your system carry Linux file capabilities with getcap, and learn to read an empty result properly. You will check single files, search a directory tree and capture a report. Every example is read-only: nothing is granted or removed.

The route

Jump straight to the step you need, or tick off Done means at the end.

1. Confirm the command and package
2. Inspect one file
3. Search a directory tree
4. Show a non-zero namespace root ID
5. Capture a report and keep empty results
6. Avoid the common traps

Allow about ten minutes. You need a shell and the libcap2-bin package. The examples use package version 1:2.66-5ubuntu2.4 on this machine.

File capabilities are security-sensitive metadata. They can give an executable selected powers without making it set-user-ID root, so treat an unexpected capability as a finding to investigate. getcap reports what is present. It does not tell you whether a program genuinely needs it.

1. Confirm the command and package

Start with an ordinary, unprivileged check. Use the package-owned path when you want to avoid a different copy earlier on PATH:

$ command -v getcap
/home/linuxbrew/.linuxbrew/sbin/getcap
$ /sbin/getcap -h
usage: getcap [-h] [-l] [-n] [-r] [-v] <filename> [ ... ]

        displays the capabilities on the queried file(s).
$ dpkg-query -W -f='${Package} ${Version}\n' libcap2-bin
libcap2-bin 1:2.66-5ubuntu2.4

The first line is the command your shell would run. The explicit /sbin/getcap call picks the installed system copy used for the checks here. The installed binary advertises -l, while this system's getcap(8) page documents -h, -n, -r and -v. This guide sticks to the documented options.

Checkpoint

If command -v points to a manually installed or development copy, repeat the examples with the path you intend to audit and check its matching man page.

2. Inspect one file

Pass one or more file names to getcap. A file with no capabilities prints nothing normally, and that is still a successful check:

$ /sbin/getcap /bin/ls
$ printf 'exit status: %s\n' "$?"
exit status: 0

Empty output here means /bin/ls has no file capabilities. It does not mean the command failed. To list every searched entry, including files with no capabilities, add -v:

$ /sbin/getcap -v /bin/ls
/bin/ls

A file that does carry capabilities shows its name and capability set. This machine reports:

$ /sbin/getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep

The suffix =ep is libcap's capability-set notation. Read it as metadata to investigate, not as a command to copy into a policy file. The output describes the file at the moment you look, and it can change after package upgrades or administrative changes.

3. Search a directory tree

Use -r for a recursive search, and give it a directory small enough to review:

$ /sbin/getcap -r /usr/bin
/usr/bin/ping cap_net_raw=ep
/usr/bin/mtr-packet cap_net_raw=ep

Your list will differ by distribution, package selection and local administration. Without -v, the output is limited to entries with file capabilities, which makes a first pass easier to read. Add -v only when you need proof that ordinary files were searched too:

$ /sbin/getcap -r -v /path/to/small-tree

Tip

Do not start at / in a busy production shell unless you mean to inspect the whole filesystem. A recursive walk can take time and produce a huge report, and access restrictions can leave the result incomplete. Begin with a package directory or a service's executable directory, then widen the scope.

Elevated privileges are not a normal prerequisite. If the tree holds directories your account cannot read, record that limitation and decide whether an authorised administrator should repeat the read-only search. Do not reach for sudo just because a result is empty.

4. Show a non-zero namespace root ID

Some file capability records are tied to a user namespace root ID, and normal output hides a non-zero value. Add -n when that distinction matters:

$ /sbin/getcap -n /usr/bin/ping
/usr/bin/ping cap_net_raw=ep

No extra number here means there was no non-zero namespace root ID to print. On a file that has one, the command includes it in the capability text. Use -n when reviewing container images, user-namespace tooling or any report that must keep this detail. It does not turn a capability into a host-wide permission.

5. Capture a report and keep empty results

For a short audit, save the output and grab the exit status straight away:

report=/tmp/getcap-report.txt
/sbin/getcap -r -n /usr/bin > "$report"
status=$?
printf 'getcap status: %s\n' "$status"
wc -l "$report"
sed -n '1,20p' "$report"

Read the status carefully:

Zero: the search completed. It does not mean the tree is free of capabilities.
Non-zero: investigate, and do not jump to the conclusion that a capability was found. Check the path, the permissions and any diagnostic text from the command.

Treat the report as sensitive operational data if it reveals internal paths or security exceptions.

Warning

If you later remove the temporary report, verify its exact path first. Deleting it is irreversible unless another copy exists, and keeping it for the length of an investigation is usually safer.

6. Avoid the common traps

Empty is not failed. Pair an empty normal result with printf '%s\n' "$?" before you run anything else.
No capability is not safe. Ordinary Unix permissions, set-user-ID bits, interpreters and service configuration still matter.
A capability is not proof of use. Trace the program and review its package or service purpose before you propose a change.
Do not alter metadata while auditing. setcap changes file security state and needs a separate, reviewed procedure with a rollback plan.
Recursive is not always complete. If the account could not read every directory, record the scope and permissions you used.

Done means

Binary identified: you confirmed which getcap binary and libcap2-bin version you used.
Empty understood: you checked a known file and told empty output apart from failure.
Scope deliberate: you used -r on a narrow tree, with -v only when ordinary entries mattered.
Namespaces covered: you used -n when namespace root ID information was relevant.
Read-only kept: you changed nothing and recorded any permission limits or incomplete traversal.