On 4/23/10 2:03 AM, Jonathan Leto wrote:
I have attached a small patch that allows me to secure PL/Parrot
against the open opcode. It comes at the cost of a single
Parrot_PMC_typenum(interp,"FileHandle") lookup, per call of the open
opcode, which is an extremely tiny performance hit and unbreaks
encapsulation.
I'm okay with this patch, as long as it's temporary (a non-specific
time-frame something like "we replace it before 2.9").
On what to replace it with:
- That direct usage of the FileHandle typeid already should have been
wrapped in a call to Parrot_get_ctx_HLL_type.
- We shouldn't be ASSERTing based on typenum there anyway, to allow for
HLL mapping of FileHandle.
- If masking entire core PMCs becomes a standard security strategy we
might want to consider a feature similar to HLL mapping in the security
layer, that cleanly substitutes the custom PMC for the core PMC.
- I'd like to see security features built into FileHandle (jonathan and
I have talked about this on IRC), altering behavior based on an
interpreter or system-wide security level setting.
- Selective enabling/disabling of opcodes is still on the menu. I'm not
as certain about selective overriding of opcodes. It's not possible now,
but might be with Lorito.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
