Definately a call to walk the tree and rip out/add bits will be
needed. But the global mask would also be handy.
> > > 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..
OK, I see a problem here. If the login shell is given the capability
by the login programme, but it's children aren't, then the example you
give doesn't work. This is because the login shell is going to start
the graphics app (i.e. X server). So what happens: X server doesn't
have the capability.
> (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).
Sorry, it doesn't make sense for this example. That's not to say that
the child mask idea cannot be of any use, but so far we don't have an
example of how it would be useful. I think you've made a similar
comment about GGI ;-)
So perhaps the child mask shouldn't be implemented until there is a
clear need (i.e. can't be reasonably done another way). It can always
be added later without too much drama.
The function to walk the tree will ensure you rip out capabilites when
you need to. You could even have another process table walking
function which changes capabilities for a specified process and all
its children. That would work fairly well, I think.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu