[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[...]
>IMO, the advantage would be that parrot apps will have a better idea >of what security model is appropriate.
Well... maybe.
Parrot apps don't get a whole lot of say here--this is more on the order of OS level security. Not that it makes a huge difference, of course.
To be specific, I was thinking about embedded parrot apps like mod_perl, where it might be nice to enforce a security policy on a per-vhost (virtual server) basis. That isn't something all parrot apps would benefit from, of course.
Ah, *that* is a different matter altogether.
I'm planning an alternate mechanism for that, though it may be a bit much--rather than restricting the dangerous things we make sure all the dangerous things can be delegated to the embedder. So file manipulation, mass memory allocation/deallocation, and real low-level signal handling, for example, all get punted to the embedder, who can then do whatever they want.
This means that when we go read some data from a file we call, say, Parrot_read, which for the base parrot'll be just read, while for an embedded parrot it may call some Apache thunking layer or something instead.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
