Hello!
I would like to try install CLISP as CGI script or as inetd server (on
Linux).
Purpose is to obtain evaluation of CL forms [or even 'echo' or
'daytime' in CL].
However I would like to "turn off" dangerous functions like
'run-shell-command' 'break' etc. My questions:
1. What functions need to be turned off?
2. Is it enough to define e.g.
(defun run-shell-command (&rest) (values)) ?
3. Does it make a difference fact that sometimes these functions
reside in 'ext' package? Do II nedd to (defun ext::run-shell-command
...) instead?
I do not understand packages well...
Regards
Miroslaw Osys
You can find a lot of information at www.alu.org. You might want to take a
look at 'Lisp Resources\Educational Resources' there.
An easy introduction to packages is referenced there and can be found at
www.flownet.com/gat/packages.pdf
It might as well be interesting to know mod_lisp from www.fractalconcept.com
This is a freeware tool to have a fast 'binding' from apache to lisp.
Andreas
"Miroslaw Osys" <········@poczta.onet.pl> schrieb im Newsbeitrag
·································@posting.google.com...
> Hello!
>
> I would like to try install CLISP as CGI script or as inetd server (on
> Linux).
> Purpose is to obtain evaluation of CL forms [or even 'echo' or
> 'daytime' in CL].
> However I would like to "turn off" dangerous functions like
> 'run-shell-command' 'break' etc. My questions:
>
> 1. What functions need to be turned off?
> 2. Is it enough to define e.g.
> (defun run-shell-command (&rest) (values)) ?
> 3. Does it make a difference fact that sometimes these functions
> reside in 'ext' package? Do II nedd to (defun ext::run-shell-command
> ...) instead?
> I do not understand packages well...
>
> Regards
>
> Miroslaw Osys
········@poczta.onet.pl (Miroslaw Osys) wrote in message news:<····························@posting.google.com>...
> Hello!
>
> I would like to try install CLISP as CGI script or as inetd server (on
> Linux).
> Purpose is to obtain evaluation of CL forms [or even 'echo' or
> 'daytime' in CL].
> However I would like to "turn off" dangerous functions like
> 'run-shell-command' 'break' etc. My questions:
>
> 1. What functions need to be turned off?
> 2. Is it enough to define e.g.
> (defun run-shell-command (&rest) (values)) ?
> 3. Does it make a difference fact that sometimes these functions
> reside in 'ext' package? Do II nedd to (defun ext::run-shell-command
> ...) instead?
> I do not understand packages well...
I'm writing a tiny, simple MUD server in CL, to exercise my webapp
framework (being written concurrently). For this, I'll be using CL
as the MUD scripting language as well, so I've been thinking about
the same problem you're stating.
My own thoughts, so far, are to create a package that only has those
functions which are third-party-safe defined and execute a silent
IN-PACKAGE before any code sent to my system. One of the functions
I'd want to shadow would be, of course, IN-PACKAGE, since if a
knowledgable user can simply change packages, there's no security.
I have no idea if this is going to work (since I haven't started on
that portion yet), but it might be something to think about.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall wrote:
> ········@poczta.onet.pl (Miroslaw Osys) wrote in message news:<····························@posting.google.com>...
>
>>Hello!
>>
>>I would like to try install CLISP as CGI script or as inetd server (on
>>Linux).
>>Purpose is to obtain evaluation of CL forms [or even 'echo' or
>>'daytime' in CL].
>>However I would like to "turn off" dangerous functions like
>>'run-shell-command' 'break' etc. My questions:
>>
>>1. What functions need to be turned off?
>>2. Is it enough to define e.g.
>> (defun run-shell-command (&rest) (values)) ?
>>3. Does it make a difference fact that sometimes these functions
>>reside in 'ext' package? Do II nedd to (defun ext::run-shell-command
>>...) instead?
>>I do not understand packages well...
>
>
> I'm writing a tiny, simple MUD server in CL, to exercise my webapp
> framework (being written concurrently). For this, I'll be using CL
> as the MUD scripting language as well, so I've been thinking about
> the same problem you're stating.
Copycat! I'm from more of the MUSE/MUSH world, so of course I had to go
and write a parser for a language similar to what you'd see in a MUSE,
and therefore didn't have this problem (although I'd love to see it
answered comprehensively, because it would help me out a great deal in
many projects that I'd like to do in CL). But my "exercise some Lisp
muscles to see if I'm fluent yet" project was indeed a MUD server.
·······@randallsquared.com (Randall Randall) writes:
> ········@poczta.onet.pl (Miroslaw Osys) wrote in message news:<····························@posting.google.com>...
>> Hello!
>>
>> I would like to try install CLISP as CGI script or as inetd server (on
>> Linux).
>> Purpose is to obtain evaluation of CL forms [or even 'echo' or
>> 'daytime' in CL].
>> However I would like to "turn off" dangerous functions like
>> 'run-shell-command' 'break' etc. My questions:
>>
>> 1. What functions need to be turned off?
>> 2. Is it enough to define e.g.
>> (defun run-shell-command (&rest) (values)) ?
>> 3. Does it make a difference fact that sometimes these functions
>> reside in 'ext' package? Do II nedd to (defun ext::run-shell-command
>> ...) instead?
>> I do not understand packages well...
>
> I'm writing a tiny, simple MUD server in CL, to exercise my webapp
> framework (being written concurrently). For this, I'll be using CL
> as the MUD scripting language as well, so I've been thinking about
> the same problem you're stating.
>
> My own thoughts, so far, are to create a package that only has those
> functions which are third-party-safe defined and execute a silent
> IN-PACKAGE before any code sent to my system. One of the functions
> I'd want to shadow would be, of course, IN-PACKAGE, since if a
> knowledgable user can simply change packages, there's no security.
>
> I have no idea if this is going to work (since I haven't started on
> that portion yet), but it might be something to think about.
You have another problem: (some-package::destroy-the-world)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> ·······@randallsquared.com (Randall Randall) writes:
> > My own thoughts, so far, are to create a package that only has those
> > functions which are third-party-safe defined and execute a silent
> > IN-PACKAGE before any code sent to my system. One of the functions
> > I'd want to shadow would be, of course, IN-PACKAGE, since if a
> > knowledgable user can simply change packages, there's no security.
> >
> > I have no idea if this is going to work (since I haven't started on
> > that portion yet), but it might be something to think about.
>
> You have another problem: (some-package::destroy-the-world)
Yes. Clearly more thought about it is required. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
·······@randallsquared.com (Randall Randall) wrote in message news:<····························@posting.google.com>...
> Yes. Clearly more thought about it is required. :)
After you've read a form to be evaluated you need to walk it to check
it is `good', which essentially entails checking symbols are OK and
that there are no other toxins in the form. It's not too hard to
write such a checker, the only possibly-nonobvious thing is that you
need an occurs check since it's fairly easy for READ to generate
circular structure.
This is far from the whole story - you need to be sure that READ is
safe itself, by the time you run the checker READ will already have
interned things in potentially bad places, and finally you need to be
sure your safe Lisp subset actually is safe. You might want to
implement your own evaluator.
The very first version of my conduits system was done to support
something like this.
--tim
On Mon, 28 Jun 2004, Peter Seibel wrote:
> You have another problem: (some-package::destroy-the-world)
Is this evidence of weapons of mass destruction in comp.lang.lisp?