I have been playing with some code that allows me to intercept access
to the File and FileHandle PMC from PIR , 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
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.
 - http://gist.github.com/373558
PS: Thanks to Austin++ for the idea about intercepting PMC's.
Jonathan "Duke" Leto
You received this message because you are subscribed to the Google Groups "parrot.dev
To post to this group, send email to parro...@googlegroups.com
To unsubscribe from this group, send email to parrot-dev+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/parrot-dev?hl=en