lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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

Cheers
Chris


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans