in reply to Safe, namespaces, B::Deparse

This is a problem if you completely discard Safe as well. Try your same snippet with a plain eval and see where that gets you - exactly nowhere. If you're going to start using eval that way then you'll want to alter your code generation accordingly to add the package in. You know the right package when you generate the code - just stick it in there as well. 

my $s = sub {
  eval qq/package @{[__PACKAGE]};
    print "PACKAGE is ",__PACKAGE__,"\n";/;
  die $@ if $@; };

[download]

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

[download]

Replies are listed 'Best First'.
Re: Re: Safe, namespaces, B::Deparse
by djantzen (Priest) on Oct 31, 2002 at 10:36 UTC

    Very interesting that a normal eval results in the same behavior; troubling too. The point though is that I want to know what happens when perl encounters package declarations that exist in the code executed within an instance of Safe. (Note that your version, because it is within a 'qq' not 'q' statement, takes the compile time version (of the enclosing program) of __PACKAGE__, which differs from the runtime version.) The reason I want to be assured of this behavior is that I'll be B::Deparse'ing arbitrary code and then checking it according to security measures via Safe::reval.

[reply]
[d/l]
[select]

      Odd? I think so. Consider that the current package is still recognized somewhat if you query it via something like B::svref_2object(sub{})->STASH->NAME. I gather that what you are actually looking for is what changes can be propogated via the symbol table back out of a Safe module. When I try to touch a global $Foo::foo within the Safe module I get a memory fault. The ->reval operation actually calls Opcode::_safe_call_sv which internally creates a new symbol table for the about-to-be executed code. Obviously if the code being executed has internal package statements then those will be respected. Is there something else you are trying to get at here that I'm missing?

      BTW do a moment of 'use strict' on your code to fix your partially renamed $parsed / $code_str variable.

      __SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

      [download]
[reply]
[d/l]
[select]

        I gather that what you are actually looking for is what changes can be propogated via the symbol table back out of a Safe module.

        That's just it. So the fact that a new symbol table is used for the untrusted code is (at least partly) responsible for creating the sandbox. And that guarantees that whatever package statements are encountered won't violate the boundaries imposed by Safe. Well I think that's very good!

        Thanks for your help diotalevi.

[reply]

In Section Seekers of Perl Wisdom