On Tue, 13 Nov 2012 12:42:41 -0500 Matthew Mondor <mm_li...@pulsar-zone.net> wrote:
> In general, if you need to enforce permission, allocation and executon > time limits, it would be better if you could use full processes (those > may be chrooted, run under the wanted permissions, use setrlimit, and > may be recycled-restarted regularily if they're allowed to serve more > than one request (for performance reason to avoid constant fork and > lisp context setup, restarting would allow to free leaked resources), > and an RPC style system would be used to send requests and retreive > results, possibly using s-exp, json, xml or a custom binary > representation)... > > Of course the problem in this case becomes shared resources, especially > ones which may be too large to easily pass as messages, if those are > needed. A database could be used, files with advisory locks, and/or a > custom system around mmap(2), sysvshm etc. I forgot to write about another alternative using bytecode though... if all code compiles to bytecode only, and the bytecode interpreter permits to impose all the limits you need. Using ECL's might limit FFI and speed however, especially if it was modified to perform extra limits checking (context-specific resource management limits, recursive/stack limits, a Spidermonkey-like iteration hook, etc). I'm not sure of its actual status, but clang+llvm can also compile to a bytecode and includes a JIT-enabled interpreter. If this can be customized enough for your needs and ECL use clang, it could be an additional interesting solution, although it could mean a lot of work if llvm needs custom changes. Of course the last but most resource-intensive way would be "cloud" virtualized clusters. Then again, in any of these scenarios, shared resources would still be a challenge. Assuming that the restricted bytecode runs in normal ECL threads, locks could be needed to access resources, and this is difficult to manage for untrusted code when at the same time avoiding pervasive low-granularity locking and deadlocks... I suppose that a language only supporting unmutable objects and transactional memory would make this easier... -- Matt ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list