[Ecls-list] Resitricted mode - possible?

[Matthew Mondor]

On Tue, 13 Nov 2012 12:42:41 -0500
Matthew Mondor <mm_lists at 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