On Sat, 2008-02-02 at 15:39 +0100, Pascal Costanza wrote:
> The straightforward way is to define your own package, and only import
> the subset of the common-lisp package that you want to support (or wrap
> the common-lisp definitions with your own definitions that can specify
> further restrictions).
>
> However, this doesn't provide the level of security you seem to be
> looking for: Your random strings could contain accesses to "cl:..." or
> even "cl::..." definitions (or also accesses to potentially internal
> symbols in other packages). Common Lisp doesn't provide a way to make
> things more secure here. The only way around this I can think of is to
> define your own parser from strings to s-expressions that can filter out
> the things you don't want. I am not aware about libraries which could
> you here, although they probably exist...
Besides creating own reader, one can simply bind *READ-EVAL* to NIL and
then sanitise READ's result (e.g. by rejecting all trees that contain
symbols not interned in package like mentioned above) before calling
EVAL. This may be simpler and less error-prone than parsing.
Maciek Pasternacki wrote:
.
>
> Besides creating own reader, one can simply bind *READ-EVAL* to NIL
> and then sanitise READ's result (e.g. by rejecting all trees that
> contain symbols not interned in package like mentioned above) before
> calling
> EVAL. This may be simpler and less error-prone than parsing.
Might be adequate for the OP's immediate needs, but
N.B. CL READ as it stands is for trustworthy* data sources only, even
with eval turned off.
You're just better off implementing your own validation for
untrustworthy data sources. It's not like parsers are especially hard
to write in common lisp.
Try READing a GB-sized single symbol (eg. GB-sized text file of
aaaaaaaaaa...) in 32-bit SBCL. SBCL nowadays actually catches it with
a "Heap Exhausted" error, but still, insta-DoS if naively exposed to
the net hung off a socket or something. It's not clear what SBCL could
do to address even this particular issue, except impose some arbitrary
maximum length on symbols. Note that even GB-sized files might be quite
reasonable to READ (some things' conventional textual format can be far
larger than their internal format - trivial example being floating
point), just probably not if they contain one giant symbol.
* you _trust_ them not to break your system/security, even though they
could.