Anonymous user
Runtime evaluation: Difference between revisions
→{{header|Common Lisp}}: Oh yes you can do sandboxing in Lisp, if you understand the package system, and what you're doing. Sorry if this is too long. Break off into a page?
(→{{header|Common Lisp}}: Oh yes you can do sandboxing in Lisp, if you understand the package system, and what you're doing. Sorry if this is too long. Break off into a page?) |
|||
Line 112:
=={{header|Common Lisp}}==
===Brief <code>eval</code> tutorial===
The <tt>eval</tt> function evaluates Lisp code at runtime.
Line 141 ⟶ 143:
(format t "~%x + y = ~a" (eval `(+ ,x ,y))))</lang>
===Sandboxing Discussion===
Sandboxing in Common Lisp can be approached in a variety of ways, none of which are standardized.
One approach to define a sublanguage and validate expressions before passing them to <code>compile</code> or <code>eval</code>. Of course, a whole different language entirely can be defined, and translated to Lisp. This is essentially the classic "trusted compiler generating safe code in an untrusted target language" approach.
One way to simplify the validator is to use the package system to create a sandbox. This is done by defining a package arbitrarily called <code>sandbox</code>. The validator then simply has to make sure that all symbols used in the expression are restricted to those which are visible inside the <code>sandbox</code> package. Inside <code>sandbox</code>, we include only those functions, operators, variables and other symbols from system packages that are safe: materials which don't allow sandboxed code to do anything harmful from within the sandbox, or to escape from the sandbox. For instance, suppose that some package <code>system</code> has a function called <code>run-shell-command</code>. We do not import <code>run-shell-command</code> into the <code>sandbox</code> package, and our validator will reject code which has references such as <lang lisp>(system:run-shell-command ...)</lang>. Therefore, the sandboxed code has no direct way to run that function. To gain access to it, it must exploit some flaw in the sandbox. One flaw in the sandbox would be the inclusion of certain package-related functions like <code>find-symbol</code>. The expression <lang lisp>(find-symbol "FOO" "BAR")</lang> will retrieve symbol <code>foo::bar</code> if it exists. The validator will not find this code because it has no embedded symbolic references to package <code>foo</code>; they are disguised as character string. A cautious approach to the sandbox should be taken: include less rather than more, and consider each expansion of the sandbox with meticulous care.
===Debugging Notes===
There are no standardized debugging facilities specific to the <code>eval</code> operation itself, but code evaluted may be affected by the current [http://www.lispworks.com/documentation/HyperSpec/Body/03_c.htm global declarations], particularly the [http://www.lispworks.com/documentation/HyperSpec/Body/d_optimi.htm <code>optimize</code> declaration]'s <code>debug</code> and <code>safety</code> qualities.
| |||