Short of parsing Perl in your solution, there's really no good way to do this. Since nothing can really parse Perl but perl, you'd have to look into the B family of modules for the best way to do this.

You could try reading all the user-supplied code in as data items which are tainted, and run some really massive untaint checks against them -- preferably something in XS that doesn't mark them as untainted until it has run several checks against each value. Then, the process just dies if you try to eval a tainted piece of code. Any solution such as this would be a hairy kludge, but it could be made to work in theory. I wouldn't volunteer to maintain such a mess in any case. Writing and maintaining the taint checks would be referred to by a choice four-letter word.

It's good to remember that Java was designed to be an applet language from the start. Perl was designed to get real work done from the start. The two design goals are difficult to have at once, especially if they are not both primary concerns from the beginning. Even Java advocates will tell you that it's a much more powerful language when run in an unrestricted application mode than as an applet in a sandbox.

If you want just a subset of Perl but with strict controls on things, you could write a parser for that subset. It could be far easier than parsing all of Perl, depending upon how much of it you want to include.

You could hack the core to make the checks for you. This would likely make Perl a slow memory hog instead of a fast memory hog like it is now. I can deal with memory issues for the most part. Memory is cheap. Time is expensive. This solution would also be a real pain. It would likely force a split between sandboxed perl and the perl core unless there's a way to keep the checks from slowing the opcodes down when they are not in use. Splits are bad. Slowing down the core for a feature not currently in use is bad, too.

If all the functions you feel are unsafe are mutable, then you could override them all to make the necessary checks before performing any actions. This, though, would practically be laguage design work in its own right. If you go through this much trouble, please make it a module. It could be useful to others once it's done.

Chris

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.