[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restricting eval

From: Mark H Weaver
Subject: Re: Restricting eval
Date: Sun, 23 Mar 2014 20:56:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Panicz Maciej Godek <address@hidden> writes:

> 2014-03-23 19:07 GMT+01:00 Grant Rettke <address@hidden>:
>> On Sat, Nov 30, 2013 at 2:26 PM, Panicz Maciej Godek
>> <address@hidden> wrote:
>>> And hence my question: is there any way to restrict
>>> the execution environment of eval, e.g. to specify
>>> which symbols should be available? (For security
>>> reasons, I wouldn't want functions like "system"
>>> or "exit" to be present in that environment)
>>> Or perhaps there's some better way to do that?
>> How did you end up achieving your goal?
> Oh, with Guile it turned out to be a piece of cake ;]
> It's thanks to first-class modules and the fact that a module can be
> provided as the second argument to eval.
> Guile actually has e.g. (ice-9 safe-r5rs), which exports a safe subset
> of Scheme, and (ice-9 null), which provides the most basic syntactic
> bindings and no functions whatsoever.
> So it is possible to either create a module in runtime using
> make-fresh-user-module and add all the necessary bindings, or to have
> some regular module prepared and obtain it using resolve-module.

It turns out that it's trivial to access any binding from any module,
even from code evaluated in a module with a restricted set of bindings.

I regret calling it a "Psyntax security hole", since Guile has never
claimed to support secure sandboxing, but it's something to keep in

I'd like to add support for secure sandboxing in a future version of
Guile, but in the meantime you'd better run it in a VM or container if
that's what you want.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]