Yes, that does the above particular case, but I'd really like to see the
"give capabilities to processes" too, so I think it makes sense to have a
special process with extra privileges irrespective of the "global" mask.
So yes, a global mask would be a simple solution, and might be part of the
complete solution, but ..
> > Oohh.. Yes, it costs you 32 bits per process. If you tell me you are
> > worried about that, I tell you that you're either lying or have extremely
> > poor judgement. In fact, you probably want another bitmask which specifies
> > which bits can be inherited by children (if you have a capability to add
> > capabilities, then you probably also want to specify that it is only added
> > to this process, not to the children of this process - that way you can
> > easily revert the capability forcibly if you want to at a later date).
> >
> > So yes, it could easily add 8 bytes per process.
>
> Why is the capabilities mask for children needed at all? I would
> assume that the init binary (for example) would be changed to do:
> fork ();
> /* Child */
> rip_out_capabilities ();
The thing I was thinking of was having a capability server that you could
ask for some capability that the server for some reason wants to serialize
completely. So the server would do something like:
.. validate request and authorization ..
sys_give_capability(CAPABILITY_XXXX, pid, NO_CHILD);
and then the server would remember the "pid" and if something happens (a
more important request for that capability comes in and takes precedence,
for example) it could forcibly do a
sys_remove_capability(CAPABILITY_XXXX, pid);
and know that there is nobody in the system that has the capability XXXX
any more (or maybe it has a list of pid's that have that capability, and
it can maintain the list completely).
Just as an example, maybe the "login" program would give the capability to
anybody who logs in on the console, and it would know that whenever the
login shell is exited (or killed), the capability to start a graphical
session automatically goes away..
(And no, I don't know that this makes sense, but I can see it perhaps
being a fairly useful set of semantics with no real downside to them: kind
of a "close-on-exec" for privileges).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu