Re: Taming constructors?
Kevin Reid <kpreid-M/[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
On Apr 30, 2014, at 23:15, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote: > ... > This now allows main (as a root of authority) to create a raiicap<T> and > pass it as a token of authority. > .. > public: > raiiclass(raiicap<raiiclass> const &); > .. > basically allows the receiver of a raiicap<raiiclass> to instantiate a > raiiclass object. Given that only root can create a raiicap<T>, and given > that a raiicap<T> can be delegated, we end up with the authority to invoke > a constructor effectively becoming somewhat of a capability. > > While the above is pretty much C++ specific code, both friends and > templates are unavailable in any other language that I know of, I think > the problem it solves is certainly not C++ specific. In fact, solving this > problem in memory secure languages may be even more important. > > Is anyone aware of similar solutions for any memory safe languages? I think that this is not a useful pattern in a capability language; that it appears useful here is due to the fact that the class "raiiclass" you are controlling may have some _statically defined authority_, which is a no-no. In a capability language, then one of these scenarios holds: 1. raiiclass was loaded/evaluated simply. It contains no authority, and therefore invoking the constructor is “just a computation” -- it has no more authority than was provided to it in the constructor arguments -- and does not need to be protected. 2. raiiclass was loaded/evaluated with some authority “in the environment”. In this case, it should be the case that access to that constructor (which, note, is no longer a process-wide singleton) is only given to the caller of that “load” operation (of which there could be many). (I've tried to phrase this to avoid assuming that the language is object-oriented or otherwise just-like-E, but I may have failed to do so perfectly.) If we assume that our memory-safe language does not have a notion of fully dynamic loading, and is more like the C (or C++) linking model where most pieces of programs are defined as singleton (static) “symbols”, then it MUST be the case that access to those symbols in themselves grant no authority. As soon as you do otherwise, you stop having a capability system. It is a mistake to include in the language design any kind of process-scoped authority (and anything which can be expressed statically without variables, such as "friend", is such), because it is fundamental to capability design that the scope of authority is implemented *by the program* and chosen *by passing references*. “The process I am in” is not a capability, so it should not give you authority. Sorry, bit of a rant there. I'd like to explain a little better but I can't quite think of what I need to say instead -- clarifying questions are welcome.. -- Kevin Reid <http://switchb.org/kpreid/>