[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Capabilities

On Fri, 11 Feb 2000, Theodore Y. Ts'o wrote:

> The "allowed" capability bit set is the set of capabilities which the
> program as allowed to *inherit* from the previously exec'ed image. This
> means that by default, once you have this capability installed, setuid
> inheritance doesn't work anymore by default!
> If you install a normal program, both capability bitsets are NULL, which
> means that if that program is run by a "root" shell, it doesn't inherit
> any privileges from the privileged shell program. This is actually a

I see real-world use of capabilities evolving in 3 stages

1) Processes voluntarily dropping capabilities. This is the stage we are
at now, and things like "bind" and "xntpd" will benefit from this. People
doing this work have hit the major stumbing block that kicked off this
thread (cannot drop uid==0 after dropping capabilities). I've sent Linus
the fixing patch.

2) Filesystem support goes in, but typical usage will be to just use the
"forced" support, to keep traditional UNIX privilege inheritance but run
suid root program with finer grained privilege. Note that stage 2) is by
no means a configuration/maintenance problem

3) The "allowed" filesystem set may or may not see usage. As mentioned,
using the "allowed" sets is a setup/maintenance pain.

The key point of this three stage plan is that at stage 2), you are
reaping benefits from filesystem capabilities without the hassle of
binaries not inheriting privilege in the traditional UNIX way


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:56    [W:0.134 / U:2.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site