Simple:  There are no permissions.  Within a method, an object may
modify any variables on that object.

The only way to modify another object's variables is to ask it to
change them, via a message.

The only way to read another object's variables is to ask it to
return them, via a message.

This has some peculiar consequences.  For instance:  an object may spoof
anything it likes.  It may spoof its location, so that it appears to
be located in a place it is not.  It may spoof its name, so it looks
like something (or someone) it's not.  It may refuse to change a variable.
etc, etc, ad nauseum.  How do we deal with these unruly objects you ask?
We don't.  We assume that these spoofings are going to occur, and plan
around them.  For instance, an object may _say_ it's in a particular
location, but it will only get the 'say' messages from that room if
it's listed in the room's "contents" field.  An object may list another
object in its contents list, but unless that object has its location
field set to that object, it may be equally unsocial/unresponsive.

For these reasons, the admin may choose to restrict programmer access,
and/or restrict which other servers may connect (since remote objects
may be operating under a different set of rules and be unruly).
The admin may choose to disable programming entirely, and simply
provide a rich set of classes of objects as a palette from which to
build.