Don't use parsing for security, use the type checker. By using 'show', you can write an instance for IO a that renders all IO harmless. Then just wrap your user's arbitrary expression in 'show.
OK, what... the... hell...? I just looked on the list archive, and sure enough that's a quote from yet another email I didn't receive. I have seriously got to figure out why I'm not seeing these emails...
careful please!-) we've had enough of that kind of issues in scripts, CGI, .. sandboxes, etc. to have learned the lesson that *this is not a minor detail*, and requires full attention to details, especially, but not only if, meta- programming is involved (interpreting input strings as programs, or using hs-plugins, template haskell).
two obvious exceptions: 'unsafePerformIO' and FFI. even expressions not involving IO might use it internally (also, you want to disallow both write and read access). less obvious: DOS-style issues, eg, filling the process table or claiming all memory. least obvious: things we've missed.
it would really be nice if someone would sit down and sort this all out in detail. there'd still be no guarantee that such a Haskell sandbox was totally safe, but at least all issues and solutions could be shared, making it as safe as the community knows how.
...which brings us back to my suggestion for "let's just deny all access to stuff it shouldn't have at the OS level - that way I can't possibly miss any edge cases". (BTW, good luck doing FFI over a text-only interface...) IIRC, there's a CLI switch that you can use to make GHC limit the amount of memory it consumes. (Actually the RTS, but since GHC is compiled with GHC...) I'm not aware of any such switch to limit the amount of time, so I might have to write actual code for that one... And then there's the issue of limiting the number of concurrent expressions being executed to some sane number. By the way... what's "plugs"? I cannot discover any information about this.