Does the root user bypass capability checking?

Question

Does the root user bypass capability checking in the kernel, or is the root user subject to capability checking starting with Linux 2.2?

May applications check for and deny access for the root user, if certain capabilities are dropped from its capability set?

By default the root user has a full set of capabilities.

The reason I'm asking is the following except from man capabilities:

Privileged processes bypass all kernel permission checks

However, nothing is said whether this rule still holds after Linux 2.2 release.

Extra: Docker removes certain capabilities from the root user while starting a new container. However, Docker doesn't use user namespaces by default, so how is the root user's capabilities restored?

man capabilities:

For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list).

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

Answer 1

The root user can be constrained in its set of capabilities. From capabilities(7):

If the effective user ID is changed from nonzero to 0, then the permitted set is copied to the effective set.

This implies that in the capability model, becoming the root user does not grant all permissions, unlike in the traditional model, where it does. The capability model is used in Linux 2.2 and later.

The bounding set of capabilities for a process is inherited from its parent. When Docker drops capabilities from the bounding set for the thread starting the container, those capabilities are dropped for the the container, affecting every process of that container, whether for the root user or otherwise. The capabilities that are left are inherited by the root user inside the container when it gains the user ID 0 (in the given namespace created by clone(2)).

The scope of these capabilities are limited by the parameters passed to clone(2), which create new namespaces for various subsystems; cgroups; and any additional security subsystems, such as AppArmor or SELinux.

Answer 2

I think you're supposed to read the whole of the first paragraph as a description of the "old way", and the second as a description of how things currently stand (for the last 21 or so years).

For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: [...] Privileged processes bypass all kernel permission checks

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.