Scribit Marcus Brinkmann dies 10/01/2007 hora 18:56: > A process C which communicates with B on a peer-to-peer basis can not > make use of g_s0, as it lacks this context (and probably wouldn't > trust it anyway), thereby making resource sharing unfeasible.
OK, let's describe it. I'll renumber my previous steps as 1-1 to 1-7, to
be able to refer to them while numbering independently other parallel
branches of steps.
Remember that A has total control on the initial capabilities initially
given to B, and you don't specify here how B would acquire a capability
to C and how this latter has been instantiated and authority it has
already been granted. I'll take the assumption that in any way, B has a
capability c0 to a facet of C implementing the desired service.
If my description is inadequate, please specify exactly authority and
state of C.
We're at the state where B has g_s0 and g_x0 (after step 1-5), and it
needs antoher service process C to do something that needs access to S.
As part of C's protocol, it's client has to provide the opaque storage
that S will use.
2-1. B creates a capability b1 to some of it's data to be consumed by C
2-2. B invokes c0.doSomethingWithService(g_s0, g_x0, b1)
2-3. C creates a capability c1 to some of it's data to be consumed by S
2-4. C invokes g_s0.useService(g_x0, c1)
- G finds g_x0 in it's map, doesn't find c1 in it's map, and thus
invokes s0.useService(x0, c1)
Where do you see infeasibility? Obviously C is able to use S, but not
opaque storage itself. If it communicates with B on a peer-to-peer
basis, then it's just behind the reference monitor. Still, G has no
knowledge of the identities of the processes involved.
Easily,
Pierre
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
