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

[Taoufik Dachraoui]

On Jun 11, 2009, at 6:43 PM, Ron Garret wrote:

>
>
> 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?
Yes, but this not what I call premature optimization. Often, when you  
try to optimize
early, usually the optimized code is complex, and this is the problem,  
adding complexity
early is not not beneficial at best. In my case I thought that by just  
writing a read macro will
solve the problem; it is not the case. But I considered this as an  
opportunity to learn
something new to me.
>
>> 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.
I looked at the l1-reader.lisp where double-colon is handled, it may  
not be difficult to
modify the code for a ccl expert (not me).
>
>> 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.

Agree, it is hard, but tractable (they did it for java, even though  
they did not solve all
security issues, but they have something running). If we wait until we  
are sure to solve all
security issues, we will never manage to do it.

>> 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.

The server can compile functions on behalf of users

>> 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
>
>
I will not be disappointed if I learn something.

Kind regards

-Taoufik