Hello Samuel, On Mon, 22 Apr 2019 at 15:35, Samuel Karp <skarp@xxxxxxxxxx> wrote: > > Signed-off-by: Samuel Karp <skarp@xxxxxxxxxx> > --- > man7/capabilities.7 | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/man7/capabilities.7 b/man7/capabilities.7 > index bcf6309e5..9f7ee670a 100644 > --- a/man7/capabilities.7 > +++ b/man7/capabilities.7 > @@ -44,6 +44,8 @@ > .\" capability, then we must also set the effective flag for all > .\" other capabilities where the permitted or inheritable bit is set. > .\" 2011-09-07, mtk/Serge hallyn: Add CAP_SYSLOG > +.\" 2019-04-10, Samuel Karp <skarp@xxxxxxxxxx> > +.\" Clarify wording for Inheritable thread capability sets. > .\" > .TH CAPABILITIES 7 2019-03-06 "Linux" "Linux Programmer's Manual" > .SH NAME > @@ -831,7 +833,8 @@ a program whose associated file capabilities grant that capability). > .TP > .IR Inheritable > This is a set of capabilities preserved across an > -.BR execve (2). > +.BR execve (2) > +when running as a root user. > Inheritable capabilities remain inheritable when executing any program, > and inheritable capabilities are added to the permitted set when executing > a program that has the corresponding bits set in the file inheritable set. This patch is not a "wfix" (a trivial wording fix), and also it's not correct. Inheritable capabilities operate regardless of UID 0. Or, to put things another way, what was the rationale behind your proposal for this change? Thanks, Michael
