[MUD-Dev] (fwd) Functional Security
J C Lawrence
claw at under.engr.sgi.com
Mon Mar 23 11:02:39 CET 1998
On Fri, 20 Mar 1998 02:51:53 PST8PDT
Miroslav Silovic<silovic at zesoi.fer.hr> wrote:
> Actually Cold seems to have solved this problem: It has the
> following mechanisms:
> 1) bind() - binds primitive function to an object. After that,
> only the methods on the object can invoke the function
> 2) native methods - C function can be interfaced with Cold in
> such a way that it appears to be ordinary method for all practical
> purposes (except that you can't list its source)
> 3) private/public/protected method flags - these do the same
> thing as in C++ - they limit the objects that can call methods
> 4) no_override flag - flag a method with this and it can't be
> overriden on the descendants of the object
I follow this model almost exactly except that I add the following:
Inheritance is at the whim of the parent, not the child.
All incoming method calls, including inheritance requests, are
passed thru a simple gauntlet which maps the inheritance tree of the
caller and event owner against an explicit list of objects, and
depending on match either accepts or denies the method call on that
basis.
ie
accept ($caller, {list, of, objects, ...})
will accept method calls from all objects whose inheritance tree
intersects one of the listed objects
reject ($caller, {list, of, objects, ...})
will reject method calls from all objects whose inheritance tree
intersects one of the listed objects by raising exception.
Method calls which are neither explicitly accepted or rejected are
rejected with an exception to the effect of "I don't know who you
are". The archicture of the object model has the relevant object
lists for each being inherited, cumulative, and non-overrideable. Oh,
and the reject list is checked before the accept list...
Note: This is cheaper than it seems as I don't maintain compound
object images for objects representing their inheritance state, but
instead keep them as a dynamic map of the inheritance tree with calls
being made to the original copies, not local copies. I also do a
*LOT* of cacheing so that checks for the same object pairs within a
given event are not repeated.
Should the incoming method call pass the gauntlet, it may then
(optionally) pass thru a second level of object-specific
authentication before being passed to the object in question.
Outside of this authentication tends to be done on the basis of
"friends" and "allies" lists, with membership (or occassionally
inheritance from) one of the listed objects being the pass phrase.
--
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------(*) Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list