CAP_SYS_ADMIN covers so many unrelated operations that the Linux manual calls it overloaded. It includes mounting filesystems and other administration tasks, and Docker does not grant it by default. When a container asks for it, treat the request as close to asking for broad host powers, and look for a narrower option.
What the manual says
The capabilities manual page lists CAP_SYS_ADMIN with a note that the capability is overloaded. The operations it permits include mount and unmount, pivot_root, swap control, setting the host name and domain name, and privileged syslog operations, among many others in a long list.
Capabilities exist to split root's power into pieces. CAP_SYS_ADMIN is the piece that never got split enough, so it became a catch all for anything that did not have a better home.
Parts that were split out
Over time the kernel gave some functions their own capabilities, and the manual records it:
| Capability | Added in | Separated from |
|---|---|---|
| CAP_BPF | Linux 5.8 | The overloaded CAP_SYS_ADMIN |
| CAP_PERFMON | Linux 5.8 | The overloaded CAP_SYS_ADMIN |
| CAP_CHECKPOINT_RESTORE | Linux 5.9 | The overloaded CAP_SYS_ADMIN |
On a recent kernel, a tool that needs only BPF or performance monitoring or checkpoint and restore can ask for the narrow capability, not the whole catch all.
What Docker does
Docker starts containers with a default list of capabilities, including chown, net bind service, setuid and setgid, kill and a few others. Docker also publishes a second list of capabilities not granted by default and that may be added. SYS_ADMIN is on that second list.
Docker's default seccomp profile also depends on the capability being absent. Its table of blocked system calls says the bpf call is denied and that it is already gated by CAP_SYS_ADMIN,. Adding the capability shifts what the profile and the defaults assume.
Why requests for it should raise questions
The capability is often added to fix an error message without finding out which operation failed. That makes it a classic workaround: it works, and it quietly hands over far more than the job needed. In an unconfined container it can also combine with other loosened settings, which is why it appears in lists of settings to review. See the run settings audit.
How to ask for less
- Find the failing operation with the error message or a trace, not by guessing.
- Map it to a specific capability using the manual page. It may be BPF, PERFMON, NET_ADMIN, SYS_PTRACE or something else.
- Try that narrow capability alone.
- Check whether a volume option, a device mapping or an image change removes the need.
- If SYS_ADMIN remains necessary, document why, and consider whether the workload belongs in a virtual machine.
A related option is user namespaces. The manual explains that holding CAP_SYS_ADMIN inside a user namespace permits some mounts in that namespace, without granting power over the host. That is the idea behind rootless designs. See subuid and subgid for how those ranges work.
For dev containers
Dev container files can add capabilities through a capAdd list or run arguments. A pull request that adds SYS_ADMIN deserves the extra review described in what a code reviewer should flag.
Safeguard does not manage Linux capabilities. It scans dependencies and images, and the free scan is at gold.safeguard.sh/scan.
Quick check
Is CAP_SYS_ADMIN granted to containers by default?
No. Docker lists it among the capabilities not granted by default that may be added.
What should I try before adding it?
Identify the exact failing operation and test the narrowest capability that covers it, such as the BPF or performance monitoring ones where they apply.
Sources
- capabilities(7), man7.org
- Running containers, Docker Docs
- Seccomp security profiles for Docker, Docker Docs
- user_namespaces(7), man7.org
Last reviewed: 19 October 2026.
