[e-lang] TextWriter/__printOn expectations/contract questions
kpreid at attglobal.net
Sat Mar 5 09:33:40 EST 2005
On Mar 4, 2005, at 19:25, Mark Miller wrote:
> There is a danger here. But so long as the extra information is
> limited to data and DeepPassByCopy objects, it would seem we already
> have this danger with the TextWriter indent level. We should examine
> how one might abuse such a channel.
> These issues remind be of the Throwable issue: Prior to the
> DarpaBrowser review, I thought that the restriction that one could
> only throw DeepPassByCopy data was adequate protection. Perhaps
> there's the same rude surprise lurking here?
It seems unlikely. This is (relatively) explicit data flow, whereas the
problem with exceptions is/was (assuming the DeepPassByCopy
restriction) that they provide a path for data flow which is implicit
in the code, and therefore 'outside' of the capability rules we expect.
My current attempt at a solution (which I have implemented in E-on-CL)
does not completely prevent this, as in order to allow *unresolved*
references to sealed-boxes to be thrown, there is an operation which
allows 'throwing' arbitrary values which any try-catch can catch
Among the consequences of this is that in order to maintain confinement
of a subgraph, all calls into it must catch every exception, or it
would be able to leak its state and authority.
This is definitely a poor situation (though I think it's slightly
better than the current one where information may *accidentally* be
I have one idea so far for a solution, which, as usual, I just thought
up while writing this message:
The pseudo-ejector which is provided to the 'server', instead of acting
as a sealer as I described before, acts as a resolver (i.e. stores a
value and becomes disabled), and the throw() does not pass any value
which is expected to reach the client.
Then, the client, if it receives a broken reference, checks the promise
which the pseudo-ejector resolves, and if it is resolved, then it
contains the problem.
This would simplify the semantics of throw()ing that I originally
proposed, as there are no 'special cases' for sealed boxes.
It has the disadvantage that there is no association between the broken
reference (created by the 'server''s vat at end-of-turn) and the
client's check of the promise, so the client might determine that its
pseudo-ejector was used, while on the server side the exception was
caught, discarded, and a different exception was thrown. This is not
necessarily bad, but it is a rather strange behavior if one is used to
exceptions in languages like Java, or even Common Lisp.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang