[E-Lang] Re: Java 2 "Security"

Ben Laurie ben@algroup.co.uk
Tue, 02 Jan 2001 19:08:11 +0000

Scott Smith wrote:
> Getting back to your question above of what is not subsumed by
> capabilities: one of the properties of the Java security model is the
> ability to temporarily raise a privilege so a more sensitive operation
> can be performed.  A flag is put on the stack (i.e. in the messaging
> wait-for chain) which signifies the point at which a privilege is
> raised, and the privilege is raised until that frame is popped (there
> are various other aspects of the model I am skipping).  To get this
> effect in a capability system you need to explicitly pass to each method
> call below the point where the privilege was temporarily raised the fact
> that this privelege was raised.  Otherwise the information that a
> privilege is temporarily raised won't reach the target.  (This explicit
> passing of raised capabilities is how we in fact encode Java stack
> inspection in one of our papers on the topic).  If you wanted to
> directly program with this kind of security, it would mean every method
> for which you wished to support this kind of security would need an
> additional argument which was the current security context.  Java
> security architecture can be viewed as a system which does all this
> bookkeeping for free for you and saves your code from going ugly.

Speaking strictly as a capabilities-programmer-in-training, it seems to
me that, firstly, you have to have "additional arguments" for everything
you want to do (i.e. the capabilities that permit you to do it) in a
capabilities system, so there's no overhead caused by having to pass
down a temporary one - you'd've had to have done that with the permanent
one anyway - and you'd grant a temporary capability by creating a proxy
to the real capability that you destroy when the thing you call with it

The experts may disagree with me.




"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff