ID:1969593
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Previously discussed in id:1829466 -- in addition to the changes already made, something akin to a '-startuplimit' parameter for DreamMaker that takes a number 'n'

n < 0: No limit to startup() calls
n = 0: No startup() calls allowed
n > 0: n is the limit of startup() calls

- Is not respected, even if specified, for child processes spawned by startup() -- current behavior applies in that scenario

- Overrides any internal 'sane' default

I could see some merit in wanting this to be configurable at runtime as well, in the case of Windows DD. In Kamuna's case, one may want to maintain a reasonable limit just for safe keeping, but still be able to increase it if need-be. For non-Windows systems, the ideal solution would probably be to set this to unlimited and set restrictions at the ulimit/limit level.

Regardless, this would make the choice explicit for the host while maintaining a reasonable default behavior.</0>
+1
As a parameter I don't see how this would work; a param could be set by startup(), which means any rogue .dmb could override the security feature.
In response to Lummox JR
Lummox JR wrote:
As a parameter I don't see how this would work; a param could be set by startup(), which means any rogue .dmb could override the security feature.

?

The process that results from the startup() call would use an n=0 limit as you mentioned that it currently does in your initial response to id:1829466 -- this parameter would effectively be ignored in the case that it's a child world.
Ah, I see what you mean there.
In response to Lummox JR
Yeah, sorry, that was not very well-worded.
A lot of it's probably on me. I've been spending most of today trying not to choke on my uvula.