The Sphere Security Model.
Alan Grimes
alangrimes at starpower.net
Wed Apr 30 03:47:58 UTC 2003
Lex Spoon wrote:
Thanks for your thoughtful response.
> It sounds like you could also use a capabilities model, if you wanted.
> The way you'd do it is to allow a sphere to be referenced from outside,
> but only if someone who has access to the sphere has passed out the
> reference. For example, BAZ could pass to FOO a reference to BAT, and
> then FOO could call walk into the BAT as well.
That is, infact, one of the primary mechanisms of Sphere! =)
It is bad policy to reveal your internal structure, so you don't tell
anyone about baz or bat for any reason ever.
HOWEVER, A rather conventional filesystem would be implemented by
passing genenral requests on to the appropriate sub-sphere.
An incoming filesystem request would be analyzed and then sent to the
appropriate subsystems.
One of the few exceptions to this transperancy is the device driver
system, A driver sphere would publish interfaces almost directly to a
registry maintained by the primary server.
> BAZ doesn't want to give out direct access to BAZOINKA, so it created
> BAT on a request from FOO that gives just a little of the power of
> BAZOINKA. Maybe BAZOINKA is a directory and BAT is a file in that
> directory.
BAZ would hide what needed to be hidden... These would include
interfaces necessary to BAT's peers but not to outside users. --
Complexity is treated as an arch vilian in this system...
> I hope you stick with your efforts on system and language design. It
> sounds like fun, and something really great could come out of it! Once
> you've got your ideas down, though, be sure and check with works by
> other designers. Have you looked at the two History of Programming
> Languages volumes published by ACM?
No, Thanx for the reff!
--
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/
More information about the Squeak-dev
mailing list
|