secure remote proxies ( was: Re: [ENH] bytecodePrimClass and
bytecodePrimEquivalentaremessage sends. Double dispatch #== )
Rob Withers
rwithers12 at mediaone.net
Sun Jan 6 21:19:06 UTC 2002
Hi Stephan,
I believe we want the same thing, although I would extend the remoteness of
an object to include objects referenced between squeak processes, in the
same image.
At 03:24 PM 1/6/2002, you wrote:
<snip>
>But they are not identical because one is a proxy, the other not: so you
>need methods like #isProxy or similar at least to get this information.
Since a proxy acts as a surrogate for the real object, clients of a proxy
should have no idea that they are talking to one. This is a Transparent
Forwarder (papers at ACM). This should include normal messages, one would
send to an object, like #class, #==, #size and so on. On the other hand,
we would want some management control, over the proxy. I think of these as
the location and behavioral aspects of our reference to the object. First
off, the casual user of a proxy should not be managing the reference; it
should be managed by a manager in a different architectural layer. Of
course, there could be a proxy control protocol, understandable by the
proxy, but it would be better encapsulated by controlling the proxy through
a Mirror. I can imagine a very strong case where the client should be
restricted from controlling the proxy. This gives us the contrary quality
of Opaqueness, so we can control how much of the underlying object is
visible to the client of the proxy.
In the case of a remote proxy, you may also want to control the policies
for migration/faulting, mutation, synchronization (sync, async-futured,
async-queued-futured, async-chained-futured like E), GC. I am sure there
are others.
> > The method nextObject and nextInstance both need to work correctly for
> > Proxies. The redirector code (I posted it after the one you replied to)
> > uses primitives in the way that Stephane Pair discusses. I got the idea
> > from him. All of these system methods are written for the redirector as
> > accepting the receiver as an argument.
>
>To give you an idea about what I'm thinking: Using proxies for objects
>residing in different Squeak
>- OS (for me Linux) processes,
>- processes on other machines.
and I would add:
- Squeak processes in the same image
For all of these we would want control identity (Transparency), security
(Opaqueness), messaging (Synchronization), location (Migration), and
mutation (Transaction)
>Then I'd have different semantics for e.g. #nextInstance meant as
>- inside one (OS) process or
>- between different ones (on the same or different machines).
I just learned about this protocol recently. In this case I feel that we
do not want global iteration of instances, but rather scoped
iteration. For instance, if we have two secured object spaces in the same
image or other images, we should not allow a user, with restricted
privileges, to gain access to instances of the Frooble class, for instance,
that is 'owned' by the other object space. However, the user will
superuser privileges, should be allowed to access instances in all managed
spaces. The ultimate would be to allow the superuser to control a users
space, but not be allowed to look at the objects inside of it. In this
way, you could have a process running on my machine, but I would be unable
to view your objects.
From reading Lex's Islands, and other materials from ACM, we need to
restrict access to primitives and globals. I think it might be done with a
security-aware compiler, that wouldn't allow compiling or installing
primitive methods, or at least system-level primitives. We would need to
proxy all globals, and bind processes to a restricted environment.
Is this a direction you are interested in?
cheers,
Rob
PS. I have a decent object comms framework which does rule-based
substitutions, and has in-pointers and out-pointers stored. I need to look
at doing a distributed GC for them. Also, I am **very** interested in
Erights and their use of chainable futures, with migratory
facilities. That would be fun to build!
>Greetings,
>
>Stephan
>
> >
> > cheers,
> > Rob
> >
> > >Greetings,
> > >
> > >Stephan
> > >
> > >
> > >PS: Haven't worked with proxies so far, but some ideas which realizations
> > >*would* (not in the near future) lead to a work with proxies.
> > >
> > >--
> > >Stephan Rudlof (sr at evolgo.de)
> > > "Genius doesn't work on an assembly line basis.
> > > You can't simply say, 'Today I will be brilliant.'"
> > > -- Kirk, "The Ultimate Computer", stardate 4731.3
>
>--
>Stephan Rudlof (sr at evolgo.de)
> "Genius doesn't work on an assembly line basis.
> You can't simply say, 'Today I will be brilliant.'"
> -- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|