Based on input from Eric Biederman
Calling cap_capable asks: Does the current process have
capability X in userns U.
I see three ways you can have that capability.
1) The current process can be in user namespace U and directly
have capability X.
2) The current process can be in the parent of namespace U and
its euid can be the euid that created user namespace U.
3) You can have be have the capability X in a user namespace
that is an ancestor of U.
Coming from the direction of your manpage text.
With respect to capabilities, the following rules apply to
nested user namespaces.
1. If a process has a capability in a user namespace has that
capability in all descendant user namespaces as well.
2. The user that creates a user namespace while in the parent
namespace has all capabilities in the created namespace
and in all descendent user namespaces.
So having said that part of my problem with your original
text is that it actually switches directions. One one rule
it is looking into the descendent user namespaces, and in the
other rule it is looking at ancestor user namespaces.
So perhaps the text should read:
With respect to capabilities, the following rules are used to
answer the question does a process P have a capability C in a
user namespace U.
1. P has the capability C if P is in user namespace U and
capability C is in process P's capability set.
2. P has the capability C if P is in the parent of user
namespace U and the euid of P is the euid that created user
namespace U.
3. P has the capability C if P has the capability C in some
user namespace V that is an ancestor of U.
Which probably gets a little extra mathematical, but it is
precise.
Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk