Privilege implementation
Felix Gallo
I am starting work on the implementation of privileges. There are
a couple of open issues I'd like to bounce before I start typing
in earnest.
1. Privs take several forms. Privs can be per-interpreter
(no computed goto), per set-of-ops (e.g., "deny everything",
"allow all IO ops"), per op (no library load, no goto, no exec),
and opcode replacement ("when you do a jump, do MY jump()");
per-namespace (read/write/create/destroy); and freeform
("I declare I have priv shabozz"). The last two seem likely
to be implemented last.
2. For courtesy and convenience, the priv system will have
some way of loading a provided namespace into an interpreter
during the creation phase (so that libraries may be loaded
without being limited by the priv system or consuming resources).
3. Newly minted or cloned interpreters may or must (respectively)
copy privs from an existing interpreter. Thawed interpreters
or any other interpreter coming from a semi-untrusted state
must reapply their privs as in 4 below.
4. If an interpreter is set up to be secure either explicitly
or via inheritance, at the end of the interpreter instantiation,
the following actions occur:
- per-opset privs fire, which iterate through the below
- per-op privs fire, which overlays the existing op
trampoline with calls to functions that generate
privilege exceptions. Note: this doesn't work if the
op trampoline is malleable intrainterpreter, but it's
a whole lot less messy and faster than the alternative.
Thoughts and guidance encouraged.
- opcode replacement is enacted by copying into the op
trampoline.
5. struct Interp is looking a little ragged. It's probably
faster that way, but there appear to be several different naming
conventions fighting it out, as well as different abstraction
impedances chittering around each other. We're gonna scare
away all those prim Python guys.
6. It's a little alarming that if you look for struct
ParrotIOData in src/ and include/, you won't find it. I found
it, but couldn't figure out why it was there. Leo?
F.
Leopold Toetsch
> 6. It's a little alarming that if you look for struct
> ParrotIOData in src/ and include/, you won't find it. I found
> it, but couldn't figure out why it was there. Leo?
Bigger parts of the interpreter like imcc and IO are distinct subsystems
and are located in separate subdirectories.
I don't know which editor you are using, but have a look at your
editor's documentation for tags or TAGS. In vim locating a structure,
function, ... is just one keystroke C< ^] > away (after "make tags").
> F.
leo
Felix Gallo
> Felix Gallo <f...@sunscreamer.com> wrote:
>
> > 6. It's a little alarming that if you look for struct
> > ParrotIOData in src/ and include/, you won't find it. I found
> > it, but couldn't figure out why it was there. Leo?
>
> Bigger parts of the interpreter like imcc and IO are distinct subsystems
> and are located in separate subdirectories.
Noted, but contrary to expectation. Seems like all source should
be under src, and all headers under include.
> I don't know which editor you are using, but have a look at your
> editor's documentation for tags or TAGS. In vim locating a structure,
> function, ... is just one keystroke C< ^] > away (after "make tags").
Good point.
I'm somewhat surprised that nobody has yet commented on the rest
of the post...I must have gotten it right. :)
F.