From: David Allouche <david@allouche.net>
Subject: Re: Secure evaluation
Date: Mon, 14 Jul 2003 17:34:20 +0200 [thread overview]
Message-ID: <20030714153420.GC29847@nemesis.xlii.org> (raw)
In-Reply-To: <Pine.GSO.4.33.0307141131320.10446-100000@sunanh>
On Mon, Jul 14, 2003 at 11:36:28AM +0200, Joris van der Hoeven wrote:
>
> I would like to use Guile Scheme for scripts inside documents,
> a bit like Javascript in Html. Does there exist any mechanism which
> forbids the use of dangerous instructions like (system "rm -rf /")
> or maybe even instructions which may lead to infinite loops?
In case you do not get a more specific answer by more knowledgeable
people here:
I remember there was some discussion about EVAL in latter versions of
GUILE (see the compat.scm file in texmacs) taking an "environment"
parameter (which is how R5RS specifies EVAL).
I believe it is possible to create an empty environment in which only
the desired functions are imported; and there is a relationship
between modules and environments (modules can be used as
environments).
Probably you could try searching the archives for "module environment
eval" and maybe "sandbox" keywords.
A quick googling yielded this thread in the archive:
http://mail.gnu.org/archive/html/guile-user/2001-09/msg00055.html
In a nutshell, that seems to be possible with guile 1.6.
This other post from Marius Vollmer mentions a "safe-eval-string"
procedure which uses such a "safe" environment.
http://mail.gnu.org/archive/html/guile-user/2003-06/msg00036.html
This one mentions the "make-safe-module" procedure which is probably
used internally with safe-eval-string.
http://mail.gnu.org/archive/html/guile-user/2001-05/msg00193.html
Another related thread:
http://mail.gnu.org/archive/html/guile-user/2001-03/msg00081.html
It also seems there are special provisions to be made for glue
functions:
http://mail.gnu.org/archive/html/guile-user/2002-10/msg00078.html
I think the main problems you would have are:
-- The cost of building the module for each evaluation. Maybe not
such a big deal.
-- Protecting the included modules from changes caused by SET! from
the sandbox module.
The latter problem is the most difficult, because to get a useful safe
environment you are going to import a bunch of utility modules in it.
However, a malevolent (or buggy) script should not be allowed to break
havoc in other modules.
But maybe I am misunderstanding how SET! interacts with modules (I
have not tested) and maybe it is not possible to modify another module
by SET!ing an imported binding.
--
-- ddaa
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2003-07-14 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 9:36 Secure evaluation Joris van der Hoeven
2003-07-14 15:34 ` David Allouche [this message]
2003-07-14 15:43 ` Paul Jarc
2003-07-15 8:01 ` David Allouche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030714153420.GC29847@nemesis.xlii.org \
--to=david@allouche.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).