Umm. for what it's worth:
Other systems that have "capability" lists (Cray UNICOS is my
example) implement them via a two level mask -
1. an allowed capability set (established during session initialization)
2. an extension to the shell: (setucat,setusrv ...) are internal
functions used to set an active capability - the desired capability
is masked against the "allowed" list before making it "active".
This two level activation eliminated the need for a very complicated
setuid sequence (and difficult to debug...). The "allowed" and "active"
capabilities can be inherited, the current process can have the "active"
capability "on" or "off".
It makes a simple security test - AND the desired active list with
the allowed list, the result is the active list. It allows administrative
control (the login will establish the allowed list), the builtin shell
utility (or library function) can enable/disable the elements of the
active list.
I realize this is not the current implementation of capabilities, but it
does work for some UNIX based systems.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/