[Rd] R in a sandbox/jail
p.murrell at auckland.ac.nz
Tue Dec 9 03:33:19 CET 2008
I set up R in a chroot jail for a course and it worked fine (students
were able to submit R code via a web form, which was
password-protected). I recall it taking a bit of setting up, but hard
to estimate how much of that was figuring out how to use chroot. I have
some notes, so might be able to help out if you have questions.
I no longer maintain the R-via-web set up, but I do automate some of the
marking of student R code submissions. See the R News 8(2) for a
description of how I use the 'compare' package for this sort of thing.
The R code submissions still need to be viewed by eye for style and
sanity, but I find it worthwhile to automate the monotonous task of
checking whether the code produces the right answer.
Barry Rowlingson wrote:
> Someone recently suggested building a system for automatically testing
> student's R programs. They would upload them to our Virtual Learning
> Environment, which would then run the code on some inputs and see if
> it got the right output. If it does, the student scores points for
> that course.
> My first thought was "you want to run unchecked, student-submitted
> code on a server that has access to students' grades?".
> Can this be done securely? The idea might be to run R in a
> chroot-jail, freshly generated for each run. The jail would not be
> able to access anything outside of it, and once the R session has
> finished the calling process can pick up the output from within the
> Maybe that's overkill. Perhaps if you run the user's code as an
> ordinary user and store the answers/results in a directory only root
> can read that would work (given no local root exploits). Other
> precautions could include limiting the runtime or cputime for the R
> session. It might be necessary to limit network access too.
> Anyone done anything like this? Personally I think there are too many
> other problems with automated systems like this, particularly that
> just because a program produces the correct output that makes it a
> good one. Sure, at the production stage that's a requirement, but I'd
> rather students learnt to program well than to program correctly -
> since correctness follows goodness but goodness does not follow
> correctness. But that's an argument for another day!
> R-devel at r-project.org mailing list
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
64 9 3737599 x85392
paul at stat.auckland.ac.nz
More information about the R-devel