Audit Linux File Capabilities with getcap

You will use getcap to check whether specific files or directories carry Linux file capabilities, search a directory tree, and make empty results meaningful. The examples are read-only: they do not grant or remove privileges. Allow about ten minutes. You need a shell and the libcap2-bin package; the examples below 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 explain 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 selects 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 stays with the documented options, apart from noting the version-specific usage output.

2. Inspect one file

Pass one or more file names to getcap. A file with no capabilities produces no normal output and still gives a useful successful check:

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

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

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

With a capability-bearing file, the normal form includes the name and capability set. For example, this machine reports:

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

The suffix =ep is capability-set notation from libcap. Read it as metadata to investigate, not as a command to copy into a policy file. The output is a property of the file at the time you inspect it and can change after package upgrades or administrative changes.

3. Search a directory tree

Use -r when you want recursive search. Give it a directory that is narrow 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 useful output is limited to entries with file capabilities, which makes a first pass easier to read. Add -v only when you need to prove that ordinary files were searched too:

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

Do not begin with / in a busy production shell unless you have a reason to inspect the whole filesystem. Recursive traversal can take time and produce a large report, and access restrictions can make the result incomplete. Start with a package directory or a service's executable directory, then widen the scope.

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

4. Show a non-zero user namespace root ID

Some file capability records are associated with a user namespace root ID. The normal output does not show 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 in this example 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 a report that must preserve this detail. It does not translate a capability into a host-wide permission.

5. Capture a report without losing empty results

For a short audit, save the output and retain the exit status immediately:

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"

A zero status means the search command completed; it does not mean the tree is free of capabilities. A non-zero status needs investigation rather than an automatic conclusion that a capability was found. Check the path, permissions and any diagnostic text from the command. Treat the report as sensitive operational data if it reveals internal paths or security exceptions.

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

6. Avoid the common traps

• Do not confuse an empty normal result with a failed command. Pair it with printf '%s\n' "$?" before running anything else.
• Do not infer that a file is safe because it has no capability. Ordinary Unix permissions, set-user-ID bits, interpreters and service configuration still matter.
• Do not treat a capability report as proof that a program uses the privilege. Trace the program and review its package or service purpose before proposing a change.
• Do not alter metadata while auditing. setcap changes file security state and needs a separate, reviewed procedure with a rollback plan.
• Do not assume a recursive result is complete when the account could not read every directory. Record the scope and permissions used.