Squeak Sandboxes?

Noel J. Bergman noel at devtech.com
Wed Aug 15 17:04:45 UTC 2001


Right now people tend to treat an image as a sandbox.  "If you break it,
create a new image."

In the spirit of further evolving the concept of protecting parts of the
environment, what would it take limit access to trusted receivers from
untrusted senders?  This would effectively allow building "sandboxes" inside
of Squeak, although that is just a subset of the consequences.

Access to a receiver could be limited at package, class, member, and
instance granularity.  Access would be gated by access control objects
implementing access policies.  Access policies could allow access based upon
various sorts of sender rights, such as the sender being (a) in a trusted
package, (b) a trusted class, , (c) executed by an authorized user.

In Java, access control is typically implemented by having the actual
receiver check for access rights (via helper objects); perhaps in Squeak we
could handle it centrally in the messaging mechanism?  This could allow
messaging to run at optimized speeds after access has been granted (some
means of rescinding access could be used to reset the messaging mechanism
for effected receivers/senders).

	---- Noel

-----Original Message-----
From: Andreas Raab

Subject: [ENH][EXPERIMENTAL] Read only globals

Richard,

> It must be acknowledged that a programming language where
> you can do
>	Smalltalk keys do: [:k| Smalltalk at: k put: nil]
> (which reliably kills Squeak 3.0) is one that is going to
> be subject to crashes of a kind not common in other programming
> languages.

But it must also be acknowledged that it's trivial to fix this problem if
you know your compiler ;) If you file in the attached CS nothing short of
#instVarAt:put: will allow you to modify any of the globals in Smalltalk. It
doesn't capture any newly created globals but that's left as an exercise to
the reader :-)

Fun things to try after filing it in ...

	Object := nil.
	Smalltalk at: #Collection put: nil.
	(Smalltalk associationAt: #CompiledMethod) value: nil.

... or whatever else.

[NB, if there are enough people lobbying for this change I might be
convinced to clean it up and post it]





More information about the Squeak-dev mailing list