[Openmcl-devel] modify lisp reader such that :: is disallowed
taoufik.dachraoui at wanadoo.fr
Thu Jun 11 12:14:53 EDT 2009
On Jun 11, 2009, at 5:56 PM, Ron Garret wrote:
> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote:
>> Users will not have access to intern, find-package, ...
>> I implemented a loader that exports public symbols and shadow
>> so that users will not be able to use any private or shadowed
>> the only problem I am facing today (as far as I can see right now)
>> is to
>> disallow users to access non exported symbols by using the double
>> colons (::)
> The "as far as I can see right now" is a very important disclaimer.
> The main problem with security is that there's a very big gap
> between appearing to be secure and actually being secure. People
> make careers out of bridging that gap, and still very often they get
> it wrong. Not that I really want to discourage you -- it's good
> that you're being ambitious, but it's important that you understand
> the magnitude of the problem you are attempting to solve.
>> I tried to use set-macro-character and set-dispatch-macro-character
>> but failed, and
>> the reason is that the lisp reader as soon as it finds a macro-
>> character the previously
>> read word will be considered as a token and there is no way to
> Why is that a problem?
> Is there a reason you don't just pre-process the string to remove
> all colons before reading it? Or simply reject any string
> containing colons?
I thought about processing the string before passing it to the reader
think it is better to leave the lisp reader deal with it (faster); but
that there is no solution at sight right now; probably only by modifying
(hacking) the ccl lisp reader.
Another way is to create a set-macro-character for #\: and throw an
but this will inhibit the use of keywords.
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?
I think the question, is what are the lisp symbols that must be
in a secure environment? streams, processes, eval, compile, ...
I just want to try hard before I abandon. I am looking forward to read
discussions about a secure lisp environment.
More information about the Openmcl-devel