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)
QUOTAs are limits on the number of resources or operations that an interpreter an allocate or perform, either in absolute terms (i.e. allocate no more than 10M of memory) or relative terms (i.e. can do only 10 IO operations per second). Quotas are tracked by parrot, and cover:
* Number of open files * IO operations/sec * IO operations total * Memory allocated * CPU time consumed * Threads spawned * Sub-processes spawned total * Simultaneous sub-processes
PRIVILEGEs are permissions to do certain things. Parrot will have a number of privileges it checks before doing dangerous operations, and user code may also assign and check privileges.
Normally parrot runs with no quotas and no privilege checking. This is the fastest way to run. Code may at any time enable privilege and/or quota checking. Once enabled code must have proper privileges to disable it again.
Each running thread has two sets of privileges -- the active privileges and the enableable privileges. Active privs are what's actually in force at the moment, and can be dropped at any time. The enableable privs are ones that code can turn on. It's possible to have an active priv that's not in the enableable set, in which case the current running code is allowed to do something but as soon as the privilege is dropped it can't be re-enabled.
Additionally, subroutines may be marked as having privileges, which means that as long as control is inside the sub the priv in question is enabled. This allows for code that has elevated privs, generally system-level code.
Continuations, when taken, capture the current set of active and enableable privs, and when invoked those privs are put into place. (This is a spot that will require some thought, since there's a potential for privilege leaks which worries me here) Non-continuation invokables (subs and methods) maintain the current set of privs, plus possibly adding the sub-specific privs.
It's actually pretty straightforward, the hard part being the whole "don't screw up when implementing" thing, along with designing the base set of privs. Personally I think taking the VMS priv and quota system as a base is a good way to go -- it's well-respected and well-tested, and so far as I know theoretically sound. Unix's priv model's a lot more primitive, and I don't think it's the one to take. (We could invent our own, but history shows that people who invent their own security system invent ones that suck, so that looks like something worth avoiding)
--
Dan--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
