It's a hard problem to get right. As well as the Safe module the other comment refers to, you may want to look into OS-level permissions.
Assuming Linux, you may be interested in:
- chroot;
- running as a sandbox user-id which owns no files (and is a member of no other groups). (Clear out that user's home dir before each run);
- ulimit and friends to control resource usage
And in this day and age, another good option is to do all this inside a hosted virtual machine. In particular, I know vmware allows you to have a disk which isn't persistent, i.e. all changes are reset on each boot.
Lastly, you said you need to allow users: "to input a perl expression or program and have it run over string."
That's a really unusual requirement. Is there any chance you could tell us why you need to do that? It's possible someone could think of an alternative approach which isn't as risky. | [reply] |
Since you need to ask, you obviously shouldn't even think about it (asking for trouble).
... here is some rope | [reply] |
Just adding to jbert's idea of sandboxing:
- On Win32 I imagine you could create a separate sandbox for perl using sandboxie.
- On Linux (or equivalent) you could probably use SELinux or AppArmor to restrict what the perl process could do.
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply]
[d/l]
[select] |
Well, there actually isn't any "good" solution to your problem. Perl is Turing-complete, and as such, you cannot prove that any perl code will run forever or end someday. Your best bet would be to run the code in some sort of virtual environment (chroot or whatever) with a time limit. Another option would be to create a language interpreter that would dramatically reduce the capabilities of the input code by allowing a very limited subset of Perl. The best would be combination of the two : write a "similiPerl" interpreter in Javascript and run it in the client browser, to avoid any unwanted effect on the server :) | [reply] |
After you finish writing similiperl, you could just provide the user with a link to download perl on his own system.
| [reply] |
Since this is clearly a dangerous idea, try to challenge the "it can't be avoided" assumption.
Taking one or two steps back, what are you trying to accomplish?
It might be possible to do the same thing in harmless client side JavaScript, or you may be able to break up the problem into harmless or less complex steps. And if you're lucky and we're all imaginative it might turn out you don't need to to this at all.
If you're lucky.
/J
| [reply] |