Howdy, I have been playing with some code that allows me to intercept access to the File and FileHandle PMC from PIR [0], which allows me to add some security to those when accessed from PL/Parrot. But I currently do not have a way to intercept calls to the "open" opcode. Defining a subroutine called "open" in the global namespace does not seem to override it.
Chromatic and I talked on IRC about a "security" runcore, which would allow replacing opcodes. The point was brought up that if you have something that allows replacing opcodes, then that itself causes another security hole. But if, at the end of replacing the necessary ops, you then replace the "op replacer", that hole is closed. A "security" runcore is definitely a great idea, and will be necessary for many advanced security features for Parrot, but if someone can think of a simpler way to replace the "open" opcode at run-time, I am all ears. Would it be possible to replace the "open" opcode with a dynop? I think that would be the smallest possible feature that Parrot could add to give PL/Parrot the filesystem security that it needs. Would making the open opcode a dynop create a noticeable decrease in performance? That is the only reason I can see that we would not want to go that route. Duke [0] - http://gist.github.com/373558 PS: Thanks to Austin++ for the idea about intercepting PMC's. -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
