Proposal: Squeak-E = Squeak x Kernel-E

Anthony Hannan ajh18 at cornell.edu
Mon Jan 27 05:28:37 UTC 2003


"Lex Spoon" <lex at cc.gatech.edu> wrote:
> Anthony Hannan <ajh18 at cornell.edu> wrote:
> 
> > > Without some kind of  global variables, you don't have Smalltalk.  Consider
> > > the globals "Array" and "World", for example.  How do you get access
> > > to these things?  Fundamentally, your code is just going to say "I want
> > > an Array class" or "I want access to the current graphical world".
> > > No matter how much syntax you clutter it with, this is conceptually
> > > a global variable.
> > 
> > Array and World don't have to be global, they can just be given to
> > classes that need them.  For convenience, they can be grouped into
> > pools.  Methods would have access only to objects in the pools held by
> > its class (and superclasses).  Giving a pool to a class is equivalent to
> > giving the class capabilities to the pool's objects.  You can even
> > restrict the capabilities by only putting proxies in the pool that only
> > understand certain messages like #new (versus #addSelector:withMethod:).
> >  I describe this pool concept in my SharedSmalltalk paper at
> > http://minnow.cc.gatech.edu/squeak/SharedSmalltalk.
> 
> You can use pools, but I still think you want dynamically-bound
> variables in the pools.  Just consider World, again.  How do you deal
> with it?  It's impractical to pass it around so that it will be in
> lexical scope all the time.  Yet, for most security policies, you will
> want different sandboxes/islands/vats/whatnot to see different World's. 
> And ideally, you'd like to have multiple sandboxes in multiple threads
> at the same time, each with it's own World variable.  Can you think of a
> solution that doesn't look an aweful lot like a dynamically-bound
> variable?

I agree World is dynamic, especially in a multi-user system.  But I
would use the execution stack as the dynamic scope, not a
sandbox/island.  World would be obtained by raising a signal.  Some
context up the sender chain would respond to it and return it.  This
implies that some object that initiated the thread knows which World to
act on, which seems appropriate for user actions and even the World
stepping loop which would have an instance variable pointing to the
actual active World.

So I think both static scope (pools) and dynamic scope (contexts) are
appropriate.  The significance is dynamic scope is not an extra concept
like islands.  I believe this is more in line with the
objects-as-capabilities concept.

The World exception class and its selectors (see typed selectors in my
SharedSmalltalk paper mentioned before) would only be accessible to
trusted classes, so untrusted intermediary contexts can't handle
or raise a World signal.

> More generally, how do you put together security policies by messing
> with the permissions of classes?  It seems against the spirit of
> capabilities to give all instances of a class immediate access to some
> resource.  It seems like you want to give access to objects, not to
> classes.  Giving access to classes sounds a lot like giving access to
> programs in an operating system, which has shown to be a problematic way
> to implement security policies.

The key is to give all instances of a class a limited (read-only,
instantiate-only, no re-assignment (:=)) capability to classes it needs.
 So I don't think its as severe as giving a program unlimited access to
a resource.  And I don't think it's against the capabilities spirit to have
all instances of a class to hold the same capability.

> PS -- having efficient class proxies as you describe sounds great,
> though it seems to have a complication if you add or remove or modify a
> clas method while a proxy to the class exists.

I picture the read-only class proxy as just delegating to the real
class, so I don't see any problems with method changes, although maybe
I'm not seeing something.

Cheers,
Anthony

P.S.  Exceptions is just a special case of dynamic scope.  You can
picture the on:do: handler as the setter and the signal as the getter. 
I have even added this general concept to Squeak and refactored
Exceptions to use it.  I will be releasing it this week with my block
closures for the standard image.  Basically, my dynamic scope look like
this:

foo
	[self bar] in: (WorldHandler newWithWorld: y).

bar
	thisContext outer world addMorph: x.

WorldHandler>>world
	^ myWorld



More information about the Squeak-dev mailing list