in reply to Re: Running untrusted perl code
in thread Running untrusted perl code

The server in question is going to be a special server, mostly dedicated to running untrusted perl code. So hopefully I can do something to prevent one person from running thirty processes. I suspect I'll require some sort of auth and just prevent a specific person from running more then one process.

As for the process limits, The two main ones I'm thinking of are RLIMIT_CPU will stop anything that tries to run for too long (and hopefully use up too much of the cpu, although it might need some more restrictrictions) while RLIMIT_VMEM will stop a script from using up too much "virtual memory" (ram + swap and so forth). As to a script that sleeps for along time, well, at the moment nothing will catch it, except that if a specific user's scripts are all sleeping for a long time, he won't be able to run any more scripts, assuming I implment some sort of "process limit" at a user level. Eventually the script in question should accumulate enough cpu time that the rlimit will kill it. (Even if it takes a long time to accumulate that much cpu time, it's obviously not doing anything to affect the box if it's sleeping all the time)

Replies are listed 'Best First'.
Re: Re: Re: Running untrusted perl code
by graff (Chancellor) on May 31, 2004 at 01:46 UTC
    Don't forget to provide a means for users to kill the jobs that they submit. That would be a useful feature for all concerned.

    Not knowing what range of tasks the untrusted perl code is expected to address, I wonder whether there might be a dilemma between keeping the server safe versus providing an adequate range of resources to support meaningful tasks (e.g. access to non-core modules? user-specifiable input data? debugging mode?) Anyway, good luck with it.

      Providing a means to kill runaway processes is definately a good idea, I'll have to see exactly what is needful.

      Perhaps I should have explained further what I'm contemplating with the use of this code. The main point is to provide a perl scripting language for a MU* type of system, so the "tasks" performed by the various bits of code should be really fairly simple, and not need to use any "outside" resources.