The open opcode

[Austin Hastings]

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
>