On Tue, Jan 28, 2003 at 02:11:39PM +0000, Matthew Byng-Maddick wrote: > On Tue, Jan 28, 2003 at 11:41:14AM +0000, Thomas Whateley wrote: > > I've been thinking about how to run un-trusted code, > > without having to audit every line, or use some sort of sandbox, > [snip] > > block to audit and be certain of what a module/program could > > do to my system. > > As author of http://dev.perl.org/rfc/353.pod, I thought somewhat about > these issues, and eventually hit a rather hard brick wall. > > What happens when you link in some module that's written natively? > Basically, my conclusion was that this was, unfortunately, still > necessary, but once you do it, then all bets about restriction and > security are off. If you can get around the necessity of that (and > only allow things which are parrot-native, then you can control it).
Hrm, maybe I just don't know what's going on, but I'm not sure why this is a problem. Couldn't "call out to native functions" or perhaps "call out to native functions in this library" or even "call out to *this* native function" be a capability? AFAIC (which means "for the applications I'm interested in"), any of the three are still Good Enough. I guess what I'm saying is, sure, you can't stop a native function (which was called from parrot code) from doing whatever it wants, but you can still prevent the parrot code from using that function in the first place (right?). -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://twistedmatrix.com/users/radix.twistd/
