[E-Lang] E FAQ

[Mark S. Miller]

[Forwarded with permission.  --MarkM]

At 05:27 PM 10/14/2001 Sunday, David Wagner wrote:
>> How does A provide some of its authority to B, such that B can exercise it 
>> other than while called by A?
>
>A must explicitly pass a closure or a proxy to B.  

I'm embarrassed to say, I never though of that in this context.  Yes, using 
closures, A can reify the authority to operate as A.  This actually makes 
Java's security substantially less offensive to me!  (All my other 
objections still remain, of course.)


>It would not be too hard to
>implement this interface as an extension to the basic stack
>introspection mechanism, I think, and then the caller could choose
>which model it prefers.

This seems to be a plausible extension by itself, but let's be careful once 
again in considering such extensions.  A dozen individually plausible 
extensions might be incoherent or worse in combination.  That's why it would 
be good to have a concrete design for a minimal language expressing some 
abstraction of the Java 2 security model.  E is a stable enough target to 
shoot at.  Java 2 itself is stable (even if too complex to reason about).  
Of course, questions such as yours are necessary on the path to other 
concrete designs.  But even one change rarely works by itself.  Rather, we 
must consider at least what the original system looks like once the 
consequences of this change have been pushed through.


>I find this an interesting design question.  In this sort of scenario,
>would we prefer to allow B to "capture" and store A's authority without
>asking A?  Or, should we require A to explicitly agree to this before
>B may "capture" A's authority? [...] 

>Do have you any thoughts on when to prefer capturable vs.
>non-capturable privileges?  How can we tell which model is better
>suited to specific application needs?  Do you think this question
>even matters?

Not much, in the sense that I have a trivial answer.  I've been coding in a 
capability style on and off for over a decade, and therefore in a style in 
which revocation needs to be explicit.  Two observations make me think that 
capabilities got this right: 1) Most capabilities never need to be revoked.  
2) When they do need to be revoked, the lifetime till revocation has never, 
in my experience, been based on call-return (even though such a lifetime 
would be easy to code, and would in theory seem to be coherent and useful).


>> Now, having been clear on the extent of my confusion and uncertainty about 
>> Java's security model, here's why I say that it's Principal-oriented.
>
>Oh, I absolutely agree.

!!  

Do you also agree that principal-orientation has the problems I point to?


>In principle, I suppose P can be fine-grained, but in practice,
>that's a misleading answer.  In practice, fine-grained privileges
>are likely to be much more unwieldy in Java than in E.  In a E-like
>capability system where object references also play double-duty as
>conveying authority, you can afford to get much finer-grained,
>because you don't have to write down as many annotations explicitly
>specifying what you want to allow.

!!!

But I'd say this applies to capability systems in general, both languages 
and OSes, rather than just E.  While my ego is tickled by "E-like capability 
systems", I don't see why the qualifier is needed.

And the notation issue is much worse than simply being "unwieldy", as 
demonstrated by the confused deputy.  
http://www.cap-lore.com/MathPhys/GRref.html hints that the issue may be even 
more fundamental than that.


        Cheers,
        --MarkM