in reply to •Re: Require everything between innermost <code></code> tags to compile.
in thread Require everything between innermost <code></code> tags to compile.

I'm curious. What kind of big issues?

Makeshifts last the longest.

  • Comment on Re^2: Require everything between innermost <code></code> tags to compile.

Replies are listed 'Best First'.
Re: Re^2: Require everything between innermost <code></code> tags to compile.
by MrNobo1024 (Hermit) on Aug 02, 2003 at 22:34 UTC
    For one, there's no protection against using up tons of memory. Someone could easily write code like "my @foo = 1..1e6; while(1) { push @foo, @foo }" and Safe will allow it.

    --MrNobo1024
    s]]HrLfbfe|EbBibmv]e|s}w}ciZx^RYhL}e^print

Re: Re^2: Require everything between innermost <code></code> tags to compile.
by diotalevi (Canon) on Aug 02, 2003 at 23:41 UTC
    {redo}
Re^3: Require everything between innermost <code></code> tags to compile.
by liz (Monsignor) on Aug 02, 2003 at 21:27 UTC
    It's not 100% safe.

    Liz

      Well, that's as much as merlyn already said, which is not a whole lot, and is why I asked more in the first place.

      Makeshifts last the longest.

        These are some of the documented issues at Safe.pm to which merlyn already referred:

        Some Safety Issues

        This section is currently just an outline (ed: emphasis mine) of some of the things code in a compartment might do (intentionally or unintentionally) which can have an effect outside the compartment.

        Memory
        Consuming all (or nearly all) available memory.
        CPU
        Causing infinite loops etc.
        Snooping
        Copying private information out of your system. Even something as simple as your user name is of value to others. Much useful information could be gleaned from your environment variables for example.
        Signals
        Causing signals (especially SIGFPE and SIGALARM) to affect your process.

        Setting up a signal handler will need to be carefully considered and controlled. What mask is in effect when a signal handler gets called? If a user can get an imported function to get an exception and call the user's signal handler, does that user's restricted mask get re-instated before the handler is called? Does an imported handler get called with its original mask or the user's one?

        State Changes
        Ops such as chdir obviously effect the process as a whole and not just the code in the compartment. Ops such as rand and srand have a similar but more subtle effect.
        In other words: it's going to be a lot of work and especially with the bunch of Perl geeks that are wandering the Monestary, you are never going to get it safe enough.

        Liz