Re: Opaque storage

[Pierre THIERRY]

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
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature