[lkml]   [1999]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: inheritable set [was Re: caps in elf headers: use the sticky bit!]
   Date: Sat, 17 Apr 1999 18:37:02 -0400 (EDT)
From: Alexander Viro <>

> You can do full POSIX capabilities and still be Unix; and the way you
> solve this problem using model outlined by the POSIX capabilities draft
> is that /usr/ucb/Mail would no longer be setuid root, so "more" would not
> be running with uid 0, and neither would the shell executing from more.
> /usr/ucb/Mail would instead have a capability which allowed it to
> override filesystem discretionary access controls, or whatever other

... i.e. would be able to modify files that don't belong to its UID. E.g.
/etc/passwd. Q.E.D.

No, because "more" wouldn't have any capabilities in its "inheritable"
set, so it would NOT inherit any capabilities which its parents had.
This is why it's important for programs to by default have a null
inheritable set, and to only inherit capabilities if they have an
explicitly set of privileges which they are allowed to inherit. This is
an integral part of the POSIX capabilities model.

The problem here is that some folks either don't understand the full
POSIX capaibility model, or keep trying to leave parts of it out in the
hopes of simplifying things. The reality is that you really do need to
implement the full POSIX capability model for things to make sense.

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.080 / U:6.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site