[DGD] Re: rlimits() question

[Frank Schmidt]

I'm sure you've looked in the README file for dgd-1.1, in the
changes-list. There it states that rlimits is a language
construct:

  rlimits (stackdepth; ticks) { code; }

Now it may be easier with an example, say you want to restrict
resources to a call from driver object with stackdepth 100 and
maximum ticksize 10000:

  rlimits (100, 10000) {
    call_other(USER, "any_function");
  }

As code there is no restriction how much you may put in it, as
long as it follows ANSI-C syntax to be put withinin a scope {...}.

If you want unlimited resources of any type, use -1 as argument,
for no change on a resource, use 0 as argument.

Now the difficulties begins, since there is no complete list over
functions called in different objects with unlimited resource-
limits (initially from the driver itself). *poke dworkin* 

I can sum all those functions I limited while creating MudOS-
alike for DGD. Though I haven't gotten the time to really test
them all, I'm sure I might have one too many or one too few:
  - ALL call_out calls
  - compile_error(), runtime_error(), remove_program() in DRIVER object
  - <create>() in AUTO object though restricting this is meaningless
  - <create>() in DRIVER object
  - receive_message() in USER object
  - open(), close() in USER object

very uncertain ones:
  - generally ALL new calls from the driver
  - rescue_file() in EDITOR object


Now, why restrict resources? Simply because you don't want the driver to
just hang on false code. Assume _your_ code is correct, but all calls to
user-defined code (out of your reach) should be limited and caught:

void sample_driver_func() {
  rlimit (100, 1000) {
    catch(call_other(master(), "check_privilege_or_whatever"));
  }
}

Why the catch? Well, it's cleaner, and it ensures _your_ code continues
to run even though the function the function called bugged/used too much
resources. 

Additionally try to avoiding resource-limiting your own drivercode,
since, well, functions handled closer to the driver should work okay and
thus you don't want bugs in code close to the driver just because the
current thread ran out of ticks.

Also, prevent over-use of rlimits adding on stackdepth and ticks. If the
function is called recursively, the limits are constantly reset/added,
thus the process might still hang.

Resource-limiting is a very important security issue, and is needed in an
environment with several users/implementators. It is vital to prevent
people from hanging the driver-process, even on purpose.


Personally I like to simplify things, and save me of the extra scope,
which tends to uglify things. So I did this:

/* default rlimits calls from driver objects */ 
#define RLIMITS_ON()   rlimits(DEFAULT_CALL_STACK ; DEFAULT_TICK_LIMIT) { 
#define RLIMITS_OFF()  } 

This means that in a close-to-driver-function I can just:

void sample_driver_func() {
  ...
  RLIMITS_ON();
  catch(call_other(master(), "check_privilege_or_whatever"));
  RLIMITS_OFF();
  ...
} 

This will set limits and catch just the calls that are "out of my 
hands" (even though I made the target functions too, they are user-
defined, and might be altered/inserted new bugs in)

Check out my package for an example on this and other stuff.


	Regards, 

	Frank Schmidt



On Wed, 20 May 1998 harte at xs4all.nl wrote:

> Quoting your message from 20 May:
> 
> [...]
> | ...how does one establish those defaults in the first
> | place? I think that if one does nothing, the defaults are no
> | limits, and if one wants to establish limits, one puts the code:
> | 
> |    rlimits {
> |       stuff ;
> |    }
> | 
> | someplace that every function call will encounter it. The question
> | is, where does one put that? I imagine receive_message in the driver
> | would work for anything generated by the user, but call_outs I'm
> | less sure about. Do the rlimits that were in place when the call_out
> | was invoked continue to apply when the call_out runs?
> 
> No, you'll have to put another rlimits() around the actual call.
> 
> By the way, 'rlimits' is technically not a kfun but part of the
> language, similar to the 'catch' keyword.
> 
> Hope that helps,
> 
> Erwin.




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