Re: Opaque storage

[Marcus Brinkmann]

At Wed, 10 Jan 2007 19:38:17 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> 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.

I am fine with that description.  To explain where B got it from: In
any non-trivial scenario B might have gotten the capability from the
user as the result of an open() operation via the powerbox, and the
user provided a capability it got from another user.
 
> 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.

This only works if C trusts B in the sense that it is willing to use
the service under the name g_s0 introduced by B to C.  It does not
work if C wants to use the resource with a service that it got from
somewhere else (for example, its own user shell).

This may be sufficient in some cases, but not in others.  Especially,
it is not sufficient in cases of mutually suspicious collaboration.

Thanks,
Marcus