[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: caps in elf, next itteration (the hack get's bigger)
   Date: 	Tue, 13 Apr 1999 23:18:17 +1000
From: Richard Gooch <>

> The whole idea of capabilities is to get rid of all-powerful users, to
> split the root powers among several people where _nobody_ has all
> powers. Any scheme that keeps a root of some sort is broken.

Whoever can grant caps is in effect all-powerful.

In a pure capability model, there is no "who" can grant caps. There is
only one or more executabes who can grant caps, and which have whatever
auditing and access control checks are deemed necessary.

One thing which people often don't "get" about capabilities is that by
default capabilities are *not* inherited by child processes. If your
shell has some large set of capabilites, child processes (such as gcc or
gmake) do not get any of these capaibilities unless those executables
have capabilities flags which allow them to inherit those capabilities.
Each executable has two sets of capabilities flags: once is the set of
capabilities which will be raised when the executable is exec'ed. The
other set is the set of capabilities which the process is allowed to
inherit from the parent process. By default, both sets of capaibilities
is the null set.

So in fact, if you want to allow a user running with a privileged shell
process which has the ability to override filesystem discretional access
controls, then any programs that user might want to run to modify the
filesystem --- cp, rm, tar, mv, etc., also need capabilities set in the
executable. So configuring a capability system is much more

- 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.158 / U:2.532 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site