lkml.org 
[lkml]   [1998]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Securelevel bitmap patch
On Sun, Mar 29, 1998 at 09:48:09PM +0100, Alan Cox wrote:
> > So tell me again: why should I not consider the BSD "one securelevel"
> > approach stupid, when I can point to another implementation that is not
> > really any more work, and obviously does a better job of it?
>
> And tell me how if you inherit securelevels you prove that every
> process is subject to the desired restraints. Do you walk the
> process tree removing bits from each process. We could do it that
> way I guess. It would cost 4 bytes per process, take a lot longer to
> set the values and do the same thing.

On fork, you just filter the capabilities through the global
securebits. When you (extremely seldom) change the global securebits,
you walk the process-tree. Alternatively, you can AND a process'
capabilities with the global securebits on each call to capable()
(which is the new name for suser() in linux-privs).

btw, using capabilities is just as fast as suser() is currently
[except that testing for 0 is faster on some architectures than
testing whether a bit is set], and is faster than checking for suser
_and_ securelevel.

astor

--
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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