When attempting to strace(1) binaries that have capabilities (or
set-user-ID-root binaries), you may find the -u <username> option
useful. Something like:
$ sudo strace -o trace.log -u ceci ./myprivprog
From kernel 2.5.27 to kernel 2.6.26, capabilities were an
optional kernel component, and could be enabled/disabled via the
CONFIG_SECURITY_CAPABILITIES kernel configuration option.
The /proc/[pid]/task/TID/status file can be used to view the
capability sets of a thread. The /proc/[pid]/status file shows
the capability sets of a process's main thread. Before Linux
3.8, nonexistent capabilities were shown as being enabled (1) in
these sets. Since Linux 3.8, all nonexistent capabilities (above
CAP_LAST_CAP) are shown as disabled (0).
The libcap package provides a suite of routines for setting and
getting capabilities that is more comfortable and less likely to
change than the interface provided by capset(2) and capget(2).
This package also provides the setcap(8) and getcap(8) programs.
It can be found at
⟨https://git.kernel.org/pub/scm/libs/libcap/libcap.git/refs/⟩.
Before kernel 2.6.24, and from kernel 2.6.24 to kernel 2.6.32 if
file capabilities are not enabled, a thread with the CAP_SETPCAP
capability can manipulate the capabilities of threads other than
itself. However, this is only theoretically possible, since no
thread ever has CAP_SETPCAP in either of these cases:
* In the pre-2.6.25 implementation the system-wide capability
bounding set, /proc/sys/kernel/cap-bound, always masks out the
CAP_SETPCAP capability, and this can not be changed without
modifying the kernel source and rebuilding the kernel.
* If file capabilities are disabled (i.e., the kernel
CONFIG_SECURITY_FILE_CAPABILITIES option is disabled), then
init starts out with the CAP_SETPCAP capability removed from
its per-process bounding set, and that bounding set is
inherited by all other processes created on the system.
