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