[DGD] My idea for the DGD driver - validate

[Robert Forshaw]

In my mudlib I have an object daemon, and it is responsible for just about 
everything regarding objects, from keeping track of inheritance to 
monitoring players idle status. There are many functions in my object daemon 
that I don't want just any object to call. In fact, just about any function 
that doesn't begin with 'query_' has some validation code at the beginning. 
I also developed a function called alert, which is kind of like a runtime 
error but noisier and is executed when an object tries to do something it 
shouldn't be doing (it sends a notification message to any admin that is 
logged in, for instance). So when naughty_object does OBJECTD -> 
hazardous_function(), hazardous_function() performs some checks on what the 
previous_object() or previous_program() was, and calls alert() if necessary 
and then error() to abort execution.

This method became rather heavy-handed, so I eventually decided to have a 
seperate function called verify_object_daemon_function_call (the name isn't 
important). Basically, all other functions that need security are declared 
private, and any object wanting to access any of those functions must call 
vodfc() first. e.g. OBJECTD -> vodfc(some_function, mixed args...)

This is so ugly though, that I hit upon the idea of having such a thing 
built in the driver. It would then be much easier to implent security of the 
nature I've described into an object.

The idea is that there would be a keyword, for example, validate, for a 
function. Any function declared with this keyword can not be called by 
anything except the driver. Now, when naughty_object does a call_other to 
OBJECTD, or whatever, if there is a validate function there then that 
function will be called instead of the function specified. If the function 
bearing the validate keyword returns zero,

To put that in code, lets say that we have:

/* naughty_object.c */


string mysterious_function()
{
  OBJECTD -> hazardous_function();
  return "";
}

/* EOF */


and then, in object_daemon.c:

/* object_daemon.c */

validate int security_function(string func_name, mixed args...)
{
  switch(func_name)
  {
    case "hazardous_function":
      if(previous_object() == naughty_object())
      {
        alert("Uh-oh, naughty_object() tried to call hazardous_function, 
call the cops!!");
        return 0;
      }
    default: return 1;
  }
  return 1;
}

string * hazardous_function()
{
  /* do something hazardous */
  return 0;
}

Here's what I propose the advantages and disadvantages to be of this method:

Advantages:

1) It makes an object far more resilient than it could be using any current 
available feature of the driver. If a function exists in an object with the 
'validate' keyword, it has many security implications for the object. There 
is no way on earth that any function can be called in that object by another 
object(except the driver of course), without calling the function bearing 
the 'validate' keyword first. Thus, there is no need to declare any 
functions as private.

2) It makes it impossible to expose a security hole even if you're the 
dopiest programmer on earth. There is no oppertunity for forgetting to 
insert a security check into every single function that you want protected. 
All security checks are condensed down to one function and so there is only 
one place to look when you need to maintain that security.

3) It saves having to type many lines of code, and much simplifies the 
process of implenting call_other security.

4) It saves ticks.

5) As an extention of the idea, it could be possible to have several 
functions with the 'validate' keyword, which are called in succession until 
one of them eventually returns 0 (stop execution) or they all return 1 
(function is called as normal, as if it were called directly via 
call_other() in lieu of current behaviour.

Disadvantages:

1) It transgresses the 'philosophy' of DGD that if a feature can be 
implented in the lib rather than the driver, it should be. I personally 
don't consider this valid in this case as I'd colligate it with the hallmark 
functions that make DGD driver to be reckoned with, like atomic functions. 
Okay, so atomic function behaviour can't be implented solely in the lib, and 
my idea can, to a degree. But not to such bullet-proof perfection. Doing it 
the mudlib is far messier and far more prone to security holes.

That's it. Tell me what you think!

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd