It's not a case of modifying FileHandle at all. The trick is to simply
replace the FileHandle pmc with a different pmc - one which implements
chroot, or fails, or throws an exception, or whatever. The interpreter
maintains a pmc dictionary, and replacing FileHandle is a snap (as it
should be).
There are a bunch of fairly obvious extensions to this suggestion, in
that there are a lot of ops that really should either be converted to
methods, or should be converted to method-shortcuts. E.g., PPSU, incr,
decr should probably be shortcuts. But having open as an opcode is
pretty silly - I don't think anyone is measuring parrot performance in
Millions of FileOpens per Second, or anything.
=Austin
Allison Randal wrote:
On 4/23/10 1:35 AM, Jonathan Leto wrote:
The issue I am getting at is that the the encapsulation-breaking makes
it so that when I override the File/FileHandle PMC's, the open opcode
still knows how to call the originals. Can we make the open opcode
actually look up the File/FileHandle PMC in the current interpreter?
The deeper problem here is that monkeypatching File/FileHandle isn't
really the right solution to secure I/O.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
