Dan, On 4/13/05, Dan Sugalski <[EMAIL PROTECTED]> 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) Just to get me back on track: Does this mean that when you spawn a thread, a separate interpreter runs in/manages that thread, or something else?
> 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. How can dropping a privilege for the duration of a (dynamic) scope be implemented? Does this need to be implemented via a parrot intrinsic, such as: without_privs(list_of_privs, code_to_be_run_without_these_privs); ..or is it possible to do so with the primitives you sketched out above? > 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. Does the code marking a subroutines must have any other privilege than the one it is marking the subroutine with? > ... Non-continuation > invokables (subs and methods) maintain the current set of privs, plus > possibly adding the sub-specific privs. Same for closures? Regards, Michael
