David Garamond wrote:
> david wrote:
>> i won't say it's broken, it's just that the Safe.pm is not finalized yet
>> and thus will undergo(probably) major changes even in the interface
>> level. example:
>
> thanks for providing the example, david. i've been reading the Safe.pm
> and the Opcode documentation, and i am seeing an issue here.
>
> as i understand it, Safe.pm works by first setting up an opcode mask for
> compilation. this means that we can reject any "mkdir" or "open" or
> other potentially dangerous operations from getting compiled at all.
> after that, we can be pretty sure that the untrusted code that we are
> running will not contain any dangerous operation, unless of course we
> give it an object reference (=capability) from outside the compartment
> so the restricted code can call an outside method/sub to do unrestricted
> operations.
>
> this is nice and all, but kind of restricted/non-transparent. suppose i
> want to allow an untrusted code access to a certain part of filesystem
> only (say, "/home/david/sandbox"). then i must disallow "open" and
the purpose of Safe.pm takes different approach than the -T option the Perl
provdies. Safe.pm maks out 'actions' that you don't want in your code. -T
blocks(until you unblock it) untrust data from entering your script.
if you restrict open(), you restrict open(). it's simple. it doesn't really
matter what part of your file system is accessed by open().
> "sysopen" opcodes. but this restrict access to all files. to achieve
> what i want, i will have to modify the untrusted source code and change
> statements like:
>
> open F, $path;
>
> to something like:
>
> $external_obj->open(\*F, $path);
yes, if that's what you want, you need to code that.
>
> where $external_obj is an object which we create and give to the
> restricted code to provide filtered access to dangerous operations.
>
> this means we can't use an untrusted code right away. we have to modify
> its source code (into "something unnatural").
>
> is there a module or something does that job for us transparently? i.e.,
> in the compilation stage, instead of disallowing an opcode, the
> dangerous opcode instruction is changed to become a call to our provided
> sub instead. this means that if the restricted code contains 'open F,
> string', that instruction is changed to "CALL filtered_open, F, string".
>
i am not aware of any module that masks Perl functions. you can create your
own though.
sub main::open{
#-- testing purpose
if($_[0] =~ m#^/#){
die("Access under / not allowed\n");
}else{
open(FILE,$_[0]) || die $!;
return FILE;
}
}
my $fh = &open('whatever');
you can probably tweak the above to make it look prettier. Or i might have
missed your point. :-)
david
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
