[Openmcl-devel] modify lisp reader such that :: is disallowed

[Ron Garret]

On Jun 11, 2009, at 9:14 AM, Taoufik Dachraoui wrote:

> I thought about processing the string before passing it to the  
> reader but I
> think it is better to leave the lisp reader deal with it (faster);

Are you familiar with the aphorism: premature optimization is the root  
of all evil?

> but it seems
> that there is no solution at sight right now; probably only by  
> modifying
> (hacking) the ccl lisp reader.

That's not the only way.  But you are right that what you want to do  
is not trivial.

> Another way is to create a set-macro-character for #\: and throw an  
> error,
> but this will inhibit the use of keywords.

That's right.  But throwing an error is not your only option.  (Note:  
I am encouraging you in this direction not because I think it's the  
right thing to do, but because there is a solution to your problem  
that you've overlooked, and I think you would benefit by finding it.   
By yourself that is.)

> About making lisp secure:
>
> Suppose you have access to a limited set of symbols (known as secure),
> and that the colons are forbidden, then how a user can access symbols
> in packages that he did not inherit?

By exploiting other weaknesses in the system.  What those are I don't  
know, I haven't taken the time to look for them.  But because CCL was  
not designed from the ground up to be secure they are almost certainly  
there to be found.  I can actually think of a long list of potential  
weaknesses, but I'm not going to tell you what they are because I  
don't want you to fall into the trap of thinking that if you can just  
patch up that list then you're done.  When it comes to security, it's  
the things you *haven't* thought of that cause the problems.  That's  
why security is so hard.

> I think the question, is what are the lisp symbols that must be  
> disallowed
> in a secure environment? streams, processes, eval, compile, ...

Earlier you said you were so worried about efficiency you didn't want  
to make an extra pass over your input strings, now you say you want to  
deny your users access to the compiler.  I guarantee you that the  
slowdown you'll get from preprocessing your input will pale in  
comparison to what you will see if you only run interpreted code.

BTW, one of the unique aspects of CCL's design is that all code is  
compiled by default, so if you want to keep your users away from the  
compiler in CCL you're really fighting an uphill battle.

> I just want to try hard before I abandon. I am looking forward to read
> discussions about a secure lisp environment.

Good for you.  Like I said, it's good that you are trying this.  Just  
don't be disappointed if you don't succeed.  You are not the first to  
go down this path.

rg