[MUD-Dev] distributed objects
darius at connect.com.au
Thu Feb 17 15:37:34 New Zealand Daylight Time 2000
>>> "Laurent Bossavit" wrote
> Kevin Littlejohn sez:
> > Phil's comment on that was that it's impossible to construct a
> > decent fight system, for instance, under that setup, because you
> > can never guarantee that
> Um... Unless I'm missing a perfectly obvious point (which wouldn't be
> the first time) don't the solutions outlined at www.erights.org for
> implementing secure "purses" also fit the bill for combat systems ?
For anyone who hasn't read it:
There's still reliance on a bunch of things, that may not be immediately
evident, though, to achieve this security. One of them that doesn't apply
in Moebius (nor, I believe, in any distributed architecture, where the 'bad
guys' have total control over the objects) is a certain non-mutability of
objects. When you've instantiated an object in E, you can't go back and
change it's methods - what they bind to, what their source code is, etc.
If you could do that, you'd instantiate a purse, then change it's decrement
method. Presto - you can hand out a decrement that's sealed by the right
thing, works fine, and does exactly what you want - purse of holding,
Ok, so the sealer performs some security checks on the method. In a
distributed world, those security checks are going to be _extremely_
interesting - and valid only until the checks stop being performed (at
which time, the holder of the object will switch methods on you).
End result - you drag more and more stuff back to the server for
verification, until you end up driving the objects data and methods on the
server from a remote point.
Caveat: I may be wrong, but I can't see where... As EQ and others have
demonstrated, people will quite happpily step "out of band" to break these
systems - I thought replacing the tiles with transparent ones was good, but
staggering lag on packets back to the server boggles me.
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev