[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Mark S. Miller]

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 
http://housechk.com/~tony/SharedSmalltalk.htm .

At the beginning of 2.1, typo:
>allows you to associated resources

2.2:
>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 
>extra overhead.

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.


2.4:
>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:

<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 
public interface.

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 
http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html 
http://www.eros-os.org/pipermail/e-lang/2002-April/006357.html .
</digression>

3:
>Since common classes are the same across users we will model them as 
>actually being identical objects that are replicated but kept in sync [2]. 
>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.

3.1:

I love your description of users and portals. I think it's exactly right.

typo:
>he may create an chat

3.2:

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.

3.4:

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.

3.5:
>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?

3.6:
>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

        Cheers,
        --MarkM