From: Joel Reymont
Subject: Safe eval of Lisp expressions
Date: 
Message-ID: <1121954067.085424.3940@o13g2000cwo.googlegroups.com>
Folks,

I would like to be able to query my custom data server using Lisp
expressions. I would pass a rule or set or rules to be evaluated for
every retrieved data point.

I don't see a way of making sure the Lisp expressions are safe, apart
from parsing them myself. Would you have any suggestions?

I saw the following bit in Portable AllegroServe

(defclass http-header-mixin ()
  ;; List of all the important headers we can see in any of the
protocols.
  ;;
  #.(let (res)
      ;; generate a list of slot descriptors for all of the
      ;; fast header slots
      (dolist (head *fast-headers*)
	(push `(,(third head) :accessor ,(third head)
			    :initform nil
			    :initarg
			    ,(intern (symbol-name (second head)) :keyword))
	      res))
      res))

Where is the #. notation described? I remember it has something to do
with not evaluating a Lisp expression or, on the contrary, evaluating
it.

    Thanks, Joel

From: Marco Baringer
Subject: Re: Safe eval of Lisp expressions
Date: 
Message-ID: <m23bq8gpvb.fsf@soma.local>
"Joel Reymont" <······@gmail.com> writes:

> Folks,
>
> I would like to be able to query my custom data server using Lisp
> expressions. I would pass a rule or set or rules to be evaluated for
> every retrieved data point.
>
> I don't see a way of making sure the Lisp expressions are safe, apart
> from parsing them myself. Would you have any suggestions?

i don't think such a thing is possible. the definition of 'safe' is
too application specific, you'd really have to implement a small
interpreter or walker which weeds out all the calls/macrso you'd
consider unsafe (though in practice it'd probbaly be easier to define
a safe set and only allow the use of those functions).

this solution wolud also allow you to cap time/resource using thoguh
it would probbaly kill the efficency of the code (how fast does the
code need to be?).

> Where is the #. notation described? I remember it has something to do
> with not evaluating a Lisp expression or, on the contrary, evaluating
> it.

http://www.lisp.org/HyperSpec/Body/sec_2-4-8-6.html

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen
From: Paolo Amoroso
Subject: Re: Safe eval of Lisp expressions
Date: 
Message-ID: <87br4wm9ug.fsf@plato.moon.paoloamoroso.it>
"Joel Reymont" <······@gmail.com> writes:

> I would like to be able to query my custom data server using Lisp
> expressions. I would pass a rule or set or rules to be evaluated for
> every retrieved data point.
>
> I don't see a way of making sure the Lisp expressions are safe, apart
> from parsing them myself. Would you have any suggestions?

This was discussed here in the past, but I'm afraid this is where my
memory stops.


Paolo
-- 
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Safe eval of Lisp expressions
Date: 
Message-ID: <REM-2005jul27-012@Yahoo.Com>
> From: "Joel Reymont" <······@gmail.com>
> I don't see a way of making sure the Lisp expressions are safe, apart
> from parsing them myself. Would you have any suggestions?

Either you're mixing up two very different tasks, or you are using
wrong language to express yourself.
READ is the function that does the parsing.
EVAL merely traverses that parse-tree.
Do you understand the difference?

SAFE-EVAL is trivial, you just write a recursive tree-traversal that
handles just the precise cases you consider "safe" and aborts anything
else that is specified in the parse tree.

SAFE-READ is the non-trivial part. You don't want to write your own
s-expression parser, you want to use the built-in READ-FROM-STRING, but
you want to specify the appropriate flags to prevent read-time
evaluation, and you want to catch all errors that might occur during
parsing or aborted read-time evaluation. We were discussing how to do
SAFE-READ-FROM-STRING etc. last year sometime. I didn't have time to
implement it back then, but I have a need for it now and might take the
time. Would you like to collaborate with me on this task? First step is
to do Google Groups search to find the ideas were were bouncing back
and forth last year, and collect together what seems like it would be
useful, then actually try the ideas and see what really works.

> Where is the #. notation described?

That's read-time evaluation. Don't bother with it, just disable it and
forbid any use of it in any code you process. I'd be too much trouble
to install hooks inside READ-FROM-STRING whereby it catches any
read-time-eval and checks it for safety by code-walking it.