[Squeak-e] Comments on Anthony's "...Shared Smalltalk"
Mark S. Miller
markm at caplet.com
Mon Feb 3 01:16:02 CET 2003
Hi Anthony, I just reread your paper, and enjoyed it tremendously once
again. Sorry for the delay on the comments.
All unattributed ">"-style quotes are taken from Anthony Hannan's
"Capabilities and Class Extensions for Secure but Extensible, Shared
Smalltalk", version dated January 2003, at
At the beginning of 2.1, typo:
>allows you to associated resources
>If you have to give out stronger capability objects, make sure the client is
>trustworthy, since it may pass the capability along to other objects. It is
>possible to create smart capabilities that confirm the sender at runtime,
>but this requires maintaining an access control list that is usually more
>trouble than handing the capabilities out correctly in the first place.
[likewise, but out of order]
>In extreme cases, where you need to give a stronger capability to an
>untrusted client, you can have the capability check who the sender or user
>is as mentioned earlier. You can have it wrap all results in new
>capabilities that also check who the sender/user is, and so on. This
>provides end-to-end security without trusting client objects, albeit with
What problem do these "smart capabilities" solve that isn't better solved
using pure capabilities? What do you mean by "confirm the sender"? What
information would you examine, and what notion of sender would you compare
it against? These "smart capabilities" looks to me like a mixture of
capability and ACL notions. Among other things, it means that a sender
effectively has extra authority because of his identity, rather than just
the authority he chooses to use. This leads to confused deputy problems.
In terms of Figures 3 and 4 of Capability Myths Demolished
http://zesty.ca/capmyths/usenix.pdf , you have arrows pointed both ways. I
think this may be approximately what Li Gong's ICAP
http://citeseer.nj.nec.com/gong89secure.html tried to do.
The next paragraph beginning with
>A fundamental difference
is just great. I don't remember seeing it explained this way before.
>We can automatically determine if an object's instance variables can be
>transferred with the object or if a proxy should be transferred instead. If
>one of the object's instance variables is truly private, i.e. no methods
>give it out, then only a proxy to the object should be given out. Otherwise,
>it is ok to transfer the object and its instance variable, since it is
>willing to give out its instance variables anyway.
This corresponds in E to the distinction between PassByCopy and PassByProxy.
E objects are by default PassByProxy. Since your paper mostly avoids
distribution issues, the following is probably a digression:
In E, to declare an object PassByCopy it must satisfy three conditions:
* OpenState -- all its instance variables must be accessible through its
interface in a standard way. I think this maps exactly to what you're saying.
* OpenSource -- the object must make its source available through a
standard request on its interface.
* Frozen -- the instance variables must be immutable. (It would be adequate
to check that they aren't assigned to.)
OpenState and OpenSource together are called Transparent. It ensures that
all the information needed to instantiate a copy is available through the
An effect of declaring an object PassByCopy is to make it Selfless. Objects
are Selfish by default. "x == y" between two Selfish objects in E means what
it means in Squeak: compare the object's creation identity, ie, their selfs.
Selfless objects have no self. "x == y" among two PassByCopy objects
recursively compares (with cycle breaking) their source and state.
Frozen and Selfless together means that PassByCopy objects can be copied
freely, and not coordinated afterwards, and nevertheless they are all still
manifestations of the same object. All the copies are still ==.
If your copied objects aren't Selfless, you probably need some kind of
per-connection interning table for each object copied over that connection,
in order to make sure that a second passing looks up the already constructed
copy on the other side.
If your copied objects aren't Frozen, then you'll need to coordinate
distribute state, which is tricky
>Since common classes are the same across users we will model them as
>actually being identical objects that are replicated but kept in sync .
>This allows them to be changed together if need be by an authorized user.
Aren't the common classes common across the universe? Who would have enough
authority to change these? I think I'm missing something.
I love your description of users and portals. I think it's exactly right.
>he may create an chat
Are you proposing that each pool dictionary be replicated across all users?
If so, then these must contain no authority as you've heard me harp on. If
you're not replicating them, but instead allowing each machine to have its
own name->variable bindings for each pool, then a shared class + separate
pool bindings = a new level of instantiation. I think I'd be happy with either
direction as long as they're taken to their logical extreme.
Really really cool. But, since you wish to prevent the class extension from
overriding the common class it's extending, what happens if the common class
later defines a method for one of the messages defined by some extension?
The common class doesn't know enough to refuse to do that. Once it's done,
then the extension in effect defines an override. I don't know what to do
about that, as I also think that overrides by extensions should be disallowed.
>A user may also add a subclass to any class. If the superclass is read-only
>then the subclass can not access the superclass's instance variables or
>pool, only its own instance variables and pool.
If the superclass sends a message to self, does the subclass receive it, as
one would naively expect?
>Finally, if the message name is found in more than one class interface,
>then those classes are presented to the user for him to choose.
In this case, the choice should be represented by making the selector in the
source explicit (eg, your later "collection.do"). Otherwise, the source text
is not the complete source.
>It also makes detached class extensions possible.
Intriguing. How do you mean? I think this one's important to understand.
I'm holding off on some further comments while I see if I can nag Dean
(cc'ed above) into finding and posting the Joule Type Extension paper he
wrote many moons ago.
Dean, nag nag. ;)
Text by me above is hereby placed in the public domain
More information about the Squeak-e