Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Best practice for user-input in eval

by humbledisciple (Novice)
on Dec 02, 2008 at 07:12 UTC ( [id://727320]=perlquestion: print w/replies, xml ) Need Help??

humbledisciple has asked for the wisdom of the Perl Monks concerning the following question:

I know, but it can't be avoided. I need to allow a user, novice or experienced (even with malicious intent), to input a perl expression or program and have it run over string. Here's the setup. This is done in a web context where the user can enter a simple or complex perl program. I will feed the user's program an input string and it should return an output string back to me. Obviously, I don't want the user to trash my hard drive, open files, etc. Should the eval operation be wrapped in an exception handler? Can I restrict the access to my file system? Is there a way to prevent the user from running and infinite loop expression and thus bring my server to a halt?

Replies are listed 'Best First'.
Re: Best practice for user-input in eval
by jbert (Priest) on Dec 02, 2008 at 08:57 UTC
    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.

Re: Best practice for user-input in eval
by Anonymous Monk on Dec 02, 2008 at 07:25 UTC
    Since you need to ask, you obviously shouldn't even think about it (asking for trouble). ... here is some rope
Re: Best practice for user-input in eval
by andreas1234567 (Vicar) on Dec 02, 2008 at 09:56 UTC
    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]
Re: Best practice for user-input in eval
by wazoox (Prior) on Dec 03, 2008 at 12:07 UTC
    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 :)
      After you finish writing similiperl, you could just provide the user with a link to download perl on his own system.
Re: Best practice for user-input in eval
by jplindstrom (Monsignor) on Dec 04, 2008 at 16:50 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://727320]
Front-paged by ysth
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (6)
As of 2024-03-28 20:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found