On Wed, 2005-04-13 at 22:03 -0400, Michael Walter wrote:
> 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?
This is usually done by creating a function "f(code) { code() }" without
any static privileges in list_of_privs. To evaluate a function g()
without those privileges, evaluate f(g), and the natural mechanisms of
the interpreter will ensure that these privileges are not held during
g().
> > 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?
Closures may also capture a concept of the current context, which is
used when they are evaluated. This is critical in, for example, the case
of system code with higher static privileges returning a closure to a
low privilege object which may evaluate it at any time.
a) The closure must not have any privileges not held by the low
privilege object, so clearly it cannot just hold its static privilege
set, it must capture a current context.
b) If it does wish to have higher privilege (very common), it may grant
(Fournet+Gordon,2003) these privileges in a dynamic scope bounded below
by itself.
S.
