On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote: > On Tue, Jan 28, 2003 at 02:11:39PM +0000, Matthew Byng-Maddick wrote: > > What happens when you link in some module that's written natively? > > Basically, my conclusion was that this was, unfortunately, still > 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.
Oh, yes, it is still a reasonable capability, but at the point that you allow that capability, you can forget any of the rest of them. (this is of course, ignoring any possible buffer overruns/format string/double-free or other types of vulnerability where you can change the executed code). > 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?). Yes, but looking at the current Perl core, a large number of the day-to-day useful modules are written native (read: in C), so you end up losing there. That's not to say that future ones will have to be, but... In reality, however, the problem as I see it is that this is a capability which, once acquired overrides all others (wheras the others can be mutually orthogonal). MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
