On Thu, 2005-04-14 at 09:51 -0700, Dave Whipp wrote: > 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
Well, given that a child thread's dynamic access control context should include the dynamic context of the parent thread at the point where the thread was spawned, No. What I describe is a (provably) correct implementation. > 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 There is no load balancing problem assuming you are synchronized on the thread-create point, which is not a major overhead, since that pretty much has to be a synchronization point in the kernel anyway. > 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). > > Is a thread really the right thing to apply these limits to? It seems to Limits are applied to privilege sets, not to threads. > 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 Yes, that's about the same. > 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. Preferably not. I fear the concept of being able to hand out privileges to low privilege threads. If the low privilege thread has access to a (willing) object with static privileges allowing the operation, then that object should perform the operation on behalf of the thread in a dynamic context created by a 'grant' operation (See Fournet and Gordon, 2003). If the low privilege thread is made up entirely of low privilege objects, then it shouldn't have the privilege under any circumstances. S.
