On 25-Nov-2008, at 9:20 PM, Michael van der Gulik wrote:
> I'm referring to encapsulation of an implementation of something. If a
> superclass is an "implementation of something", a subclass is a user  
> and
> extender of that "implementation of something".

Well, umm, no, I don't think so -- a subclass is, by definition, an  
_extension_ of the class it inherits from.

> Allowing a subclass direct
> access to the innards of its superclass prevents that superclass  
> from being
> able to protect its carefully guarded state from meddling by  
> subclasses.

If such protection seems necessary then I'd say there's something  
extremely broken in the overall design of that part of the class  
hierarchy in question.

> This is relevant in the area of secure programming for my SecureSqueak
> project, although I can't think of a good example yet where it would  
> really
> be a problem.

Perhaps you could start by explaining some of the theory about how any  
kind of "secure" (do you really just mean "safe"?) programming  
techniques can be aided by what you seem to be describing here.

> Say you have a class with a carefully guarded secret in it. It would  
> then be
> possible for untrusted, remotely loaded code to be a subclass of  
> that class
> and then give out that secret.

Ah, perhaps you don't mean secure programming, but rather actual data  
security.

I really don't understand your security model here.  It doesn't seem  
to be related to or compatible with the object oriented programming  
model of Smalltalk at all, at least as I understand things.  A  
subclass is an extension of its superclass.  An object which is an  
instance of the subclass inherits all the qualities of the  
superclass(es) too.

An object that is only derived from the "superclass" is a separate  
object.  And it isn't an instance sharing any quality of any subclass  
that may inherit from its class, let alone sharing any data with any  
instance of any subclass.

> This makes several assumptions though:
> firstly that you can somehow create an instance of your subclass  
> with that
> secret state (which is unlikely) and secondly that the remotely  
> loaded code
> actually has access to the class and is able to become a subclass of  
> it.

Indeed, that part is just plain nonsensical.

You seem to be confusing the definition of objects with the actual  
objects themselves.

If you're really trying to create a model where objects created as  
instances of classes which have been remotely loaded, then you need to  
create some sort of partitioned VM storage model such that the VM will  
only pass messages between objects within a given partition, and  
perhaps one way from a parent partition.  I don't think this can  
really work very well in a Smalltalk system though, but perhaps I'm  
missing something.  If I load untrusted code I basically have to do it  
in a different VM image which has been carefully constructed so as to  
contain only public data and which has built-in controls which will  
only allow it to access those parts of the outside system environment  
which I would feel safe allowing untrusted code to access.  Perhaps  
this VM image could be dynamically created and managed by another full  
"parent" VM.  If I'm not mistaken this is kind of sort of how the Java  
VM security model is supposed to work.

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081125/7b47ea4a/PGP.pgp