On Tue, Jan 4, 2011 at 10:26 AM, Zed A. Shaw
I'm toying with a small idea to let people upload bits of chuck code to a website and then have it play out to the world. I haven't started coding anything yet, but I was wondering how hard it is to put ChucK into a safe environment so that it can't touch the OS? In Lua I'd do that by ripping out the various OS features. Is there a similar thing with Chuck?
My roommate did this project a few years ago (actually, it was collaborative ChucKing), but I don't know if he handled the security issues. I'll ask. However, since that time more unsafe APIs have been added, so even if they did, their patch might not be too useful. I think it would take some work to find all the places where ChucK performs operations you wouldn't want to do in a sandbox. There's no --sandbox option, though the undocumented --standalone gets you started. It turns off network listening for on-the-fly VM commands. AFAIK it's only referenced in the VERSIONS file and chuck_main.cpp. You'd also have to patch the file I/O calls that were added recently, the various types of network calls like OSC, the ways of saving audio to disk (as with WvOut), and probably others I'm not thinking of. Nothing difficult, it's just you might not be able to know when you've plugged all the holes. And Stephen's right that you'd definitely need a watchdog outside of ChucK since a shred can halt virtual time indefinitely with an infinite loop. If you're spawning a ChucK per job that's simple, but a long-running ChucK would be complicated. There's --watchdog (another undocumented flag), but it's not clear how/if that works. -- Tom Lieber http://AllTom.com/ http://ckvlang.org/