Bug 215910
| Summary: | man page for cap_reset_ambient() incorrectly claims CAP_SETPCAP is needed | ||
|---|---|---|---|
| Product: | Tools | Reporter: | Tinkerer One (tinkerer) |
| Component: | libcap | Assignee: | Andrew G. Morgan (morgan) |
| Status: | RESOLVED DOCUMENTED | ||
| Severity: | normal | CC: | morgan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | all | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
Thanks for the bug report! Fixed with: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=9a9579181897a62dc107b121f139a319d7e297fa |
The man page (cap_get_proc.3) claims: cap_reset_ambient() resets all of the ambient capabilities for the calling process to their lowered value. To complete successfully, the prevailing effective capability set must have a raised CAP_SETPCAP. Note, the ambient set is intended to operate in a legacy environment where the application has limited awareness of capabilities in general. Executing a file with associated filesystem capabilities, the kernel will implicitly reset the ambient set of the process. Also, changes to the inheritable set by the program code without explicitly fixing up the ambient set can also drop ambient bits. This is not correct. The kernel will let any process drop its ambient set with this function without CAP_SETPCAP. Verified as follows: $ sudo capsh --inh=cap_setuid --user=$(whoami) --addamb=cap_setuid == --print --noamb --print | grep Current Current: cap_setuid=eip Current IAB: ^cap_setuid Current: cap_setuid=eip Current IAB: cap_setuid