Add CAP_CHOWN to permitted capability set#12908
Add CAP_CHOWN to permitted capability set#12908bryancall wants to merge 1 commit intoapache:masterfrom
Conversation
Add CAP_CHOWN to the permitted capability set retained after privilege drop. This allows plugins that perform cert file backup writes to set root ownership on newly created files when certs are restricted to root:root 600. Like CAP_DAC_OVERRIDE, CAP_CHOWN is held in the permitted set only and must be explicitly promoted to the effective set before use. It is not active during normal operation.
There was a problem hiding this comment.
Pull request overview
This PR adds CAP_CHOWN to the permitted capability set to enable plugins to change file ownership, specifically to support TLS certificate management plugins that need to set root:root ownership on backup certificate files.
Changes:
- Added
CAP_CHOWNto theperm_listarray inRestrictCapabilities(), making it available in the permitted set (but not the effective set) after privilege drop
|
|
||
| // Capabilities we need. | ||
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER}; | ||
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_CHOWN}; |
There was a problem hiding this comment.
Adding CAP_CHOWN to the permitted set without a corresponding privilege level in the ElevateAccess class makes it effectively unusable. Currently, ElevateAccess supports FILE_PRIVILEGE (maps to CAP_DAC_OVERRIDE), OWNER_PRIVILEGE (maps to CAP_FOWNER), TRACE_PRIVILEGE (maps to CAP_SYS_PTRACE), and LOW_PORT_PRIVILEGE. To actually use CAP_CHOWN, you need to either:
- Add a new privilege level (e.g., CHOWN_PRIVILEGE = 0x10u) to the ElevateAccess class in include/tscore/ink_cap.h
- Update the acquirePrivilege() function in src/tscore/ink_cap.cc to handle this new privilege level by elevating CAP_CHOWN to the effective set
Without these changes, CAP_CHOWN will remain in the permitted set but cannot be elevated to the effective set, making it impossible for plugins to use fchown() as described in the PR description.
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_CHOWN}; | |
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER}; |
|
|
||
| // Capabilities we need. | ||
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER}; | ||
| cap_value_t perm_list[] = {CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_IPC_LOCK, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_CHOWN}; |
There was a problem hiding this comment.
This line exceeds the maximum line length of 132 characters (currently 143 characters). According to the C++ style guidelines for this repository, lines should not exceed 132 characters. Consider breaking this into multiple lines or using a more compact formatting.
Summary
Add
CAP_CHOWNto the permitted capability set retained byRestrictCapabilities()after the privilege drop from root to the unprivileged user.This enables plugins that manage TLS certificate files to set
root:rootownership on backup copies they write to disk, supporting deployments where cert files are restricted toroot:root 600insideroot:root 700directories.Changes
src/tscore/ink_cap.cc-- AddedCAP_CHOWNtoperm_listinRestrictCapabilities(). LikeCAP_DAC_OVERRIDEandCAP_FOWNER, it is retained in the permitted set only (not effective). A plugin must explicitly promote it to the effective set before use.Security Considerations
CAP_CHOWNallows changing file ownership. It follows the same security model asCAP_DAC_OVERRIDE(already retained): held in the permitted set but not in the effective set during normal operation. A plugin must use RAII-style elevation to briefly promote it, then drop it immediately after thefchown()call.Testing
Verified on Fedora 43 with libcap 2.76:
CAP_CHOWNappears inCapPrmbut notCapEffafter startupfchown()succeeds when the capability is elevated