On Fri, Jul 4, 2014 at 11:48 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Fri, Jul 4, 2014 at 8:10 PM, Matt Oliveri <[email protected]> wrote: >> The endpoint identifier is the OID field in an endpoint >> capability? So the implementing process gets to see that, but not the >> invoker, unless they are authorized to use CapBits on it? > > No. Short of using CapBits, which is wielded by exactly one program, nobody > ever sees the OID. The endpoint ID is set by the holder of the endpoint > capability. Having set the ID, you then fabricate an Entry capability, which > is a different capability type that also points to the endpoint object: > > http://coyotos.org/docs/ukernel/spec.html#coyotos.Endpoint
Ah, OK. Looks like I should read chapter 5 too. >> It looks >> like Coyotos itself doesn't need to care what constitutes an object >> implemented by an application. It just needs to faithfully report the >> (uninterpreted) protected payload and OID to the appropriate process. > > That is exactly correct. ...except that OID should've been endpoint ID? >> In that case how would Coyotos applications usually implement object >> identity comparison? Say, to determine if images linked from two parts >> of a document are the same? > > As the receiver on an endpoint, you know what endpoint was invoked and with > which protected payload. If those two things match, then the invoked > capabilities were the same. So there's a trick where the caller invokes one > cap passing the other, and then the serving object invokes the second to > extract the endpoint ID and payload of that. So basically, you ask one image to compare itself to the other, hoping it would recognize itself. What if these were secure objects possibly implemented in different processes, and you don't want to grant one to the other? Actually we don't need to get into details, the point is that it isn't the kernel's problem. >> > The operation that inspires "guarded open" is the identifyEntryWithBrand >> > operation on Coyotos processes: >> > >> > http://coyotos.org/docs/ukernel/spec.html#coyotos.Process >> >> So the brand is the guard, and it might provide authority because it >> reveals the endpoint's protected payload and ID? > > Yes and no. The brand is the guard, but it doesn't "provide" authority, > except in the sense that holding it is necessary to de-encapsulate the > object. This is why I say authority is really a function of a set of capabilities. The authority of a single capability depends on what other capabilities you have, and thus isn't well defined. >> I'm not sure why you showed me this. It seems like Coyotos doesn't >> have much to say about object identity for application-specific >> objects. > > Right. And that's the point. You can build very rich systems without having > much to say about object identity, and without letting applications in > question even ask the question about object identity. You reminded me that E and Joe-E disable object comparison by default. Where does BitC stand on primitive object comparison? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
