Re: Lisp security
- From: Peter Herth <p.herth@xxxxxxxxxxx>
- Date: Mon, 31 Oct 2005 15:33:53 +0100
John Thingstad wrote:
Obviously Lisp is not prone to buffer overfow controls. (unless optimations turn bounds checking off)
But there is the question of Java.final.
Apperaently there is no equivalence in Lisp.
Simularly there is the possibility to change inheritance after runtime.
Also decaring code after runtime.
Obviously if you get trough the outer defenses Lisp is chanseless.
Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
I think that final classes and sandboxes are two distinct things. To construct a sandbox you need to create an environment in which the running program has no access to the "outer" world, like access to the filesystem and operating system calls - remove all corresponding functions from the environment.
Final classes come IMO from the same paranoid object philosophy that brought us private variables/methods. They are supposed to enforce the
clean usage of libraries - in practise more often create encumberments than are beneficial to the code quality. One of the worst misdesigns of the Java language was making String a final class instead of an interface and letting the current String and StringBuffer classes just implement that interface. This is one of the reasons, that while the Hotspot JVM is basically very fast, many Java programs are slow, because you can't get around this (inefficient) string implementation.
Peter
-- Ltk, the easy lisp gui http://www.peter-herth.de/ltk/ .
- References:
- Lisp security
- From: John Thingstad
- Lisp security
- Prev by Date: Re: Eval performance
- Next by Date: Re: diff. betw. equal and eq on simbols
- Previous by thread: Re: Lisp security
- Next by thread: Re: Lisp security
- Index(es):
Relevant Pages
|
