[comp.lang.lisp] Lisp module security

novick@uoregon.UUCP (David G. Novick) (11/19/87)

Vallury Prabhakar asks about keeping users from calling functions not
meant for the user.  Barry Margolin suggests that this is not
possible.  Here is my analysis, which is that there are a number of
ways to do this.

Some lisps, FranzLisp for instance, have a top-level function which
comes up automatically and thereafter runs any time the system would
have run the top-level read-eval-print loop.  Thus if the user invokes
your lisp program, he or she will get the function you wanted rather
than the read-eval-print loop.  CommonLisp also has top-level
customizing facilities (see Steele, pp. 324-326).  This is a lot
like changing a Unix user's login program from the shell to some other
program.

Aside from enforcing a restriction of the top level to some specific
application function, you can also provide a top level which enforces
exactly the kind of protection Vallury wants.  This can be done by
writing your own read-eval-print function and setting the top-level
function to this.  Your function should just check the type of the
called function.  The hack way to do this is just to keep a list of
acceptable user functions.  A better way is to type the functions
themselves somehow; the implementation of this depends on the lisp.
Note that advanced versions of this loop should recursively check
arguments to top-level functions as well.

Actually, I think you may have confused an interpreter with a
compiler.  (I'm using a simplified common usage of these terms.  I
know that the issues are more complex than this, but sophisticated
readers will, I expect, understand both the thrust of my analysis and
why I've phrased it this way.)  In an interpreted pascal, the user
always has the top-level interpreter around, and can call any
procedure or function you've defined.  This is exactly the same
problem you've identified for interpreted lisp (except maybe worse
because pascal won't have a top-level function you can change).

I hope this helps you solve your problem.

David Novick			       |   voice:  (503) 686-4408
Dept. of Computer and Info. Science    |   bitnet: novick@uoregon
University of Oregon		       |   uucp:   {tek|hp-pcd}!uoregon!novick
Eugene, Oregon  97403		       |   csnet:  novick@uoregon.edu