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?
We'd decided that each thread has its own interpreter. Parrot doesn't get any lighter-weight than an interpreter, since trying to have multiple threads of control share an interpreter seems to be a good way to die a horrible death.
> Each running thread has two sets of privileges -- the activeprivileges 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?
When a priv is dropped it stays dropped until it's reinstated. If code drops a priv that it can't re-enable then the priv is gone. (There are going to be issues with privileges attached to continuations, since this could potentially mean that dropped privs get un-dropped when you invoke a return continuation, though dropping a privilege could ripple up the return continuation chain)
> Additionally, subroutines may be marked as having privileges, whichmeans 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?
Dunno, that's something we'll need to work out. It's possible that sub marking needs to be done externally -- that is, it's bytecode metadata or something like that which requires system privileges of some sort to set. (Though there are issues with that) Marking code as privileged is really a system administration task, though we've not really put much thought into administering a parrot system yet.
> ... Non-continuationinvokables (subs and methods) maintain the current set of privs, plus possibly adding the sub-specific privs.
Same for closures?
Yeah, I think so. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
