[Openmcl-devel] modify lisp reader such that :: is disallowed
ron at awun.net
Thu Jun 11 12:43:53 EDT 2009
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
> (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
> 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
> 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.
More information about the Openmcl-devel