Dan Sugalski wrote:
All security is done on a per-interpreter basis. (really on a per-thread basis, but since we're one-thread per interpreter it's essentially the same thing)...* Number of open files * IO operations/sec * IO operations total...
Can an "application" get more resources simply by spawning threads? If the answer is "no, parent and child must divide share their quotas" then there is a load balancing problem. If the answer is "yes", then there's no real protection at all. A threads-per-second limit isn't an answer here, either (a malicious app could sit around for a few hours, launching threads at a low intensity, until it has enough to bring down the system).
Spawning threads may require a privilege, and there should be a quota for it, so the number of spawned threads could be managed.
I can see sharing quotas across multiple threads, though there are issues there (like sharing CPU time) as well.
Is a thread really the right thing to apply these limits to? It seems to me that there needs to be some sort of token (cf. cash; cf "capability") that an application can obtain/spend/refresh to do these ops. An application could share its token(s) with any threads it creates. It could probably even "loan" its token to a backgroud thread that does some operation on behalf of many other threads.
Well, and interpreter is as fine-grained as we can get, and you're right, we may want to get a bit broader and share quotas amongst multiple threads. I don't know that we want to get much fancier than grouping threads together, though -- while I can see it being useful in a few cases, I'm not sure in practice that anyone'd actually want to do that.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
