On Fri, Oct 24, 2008 at 5:16 PM, Adam Jones <[EMAIL PROTECTED]> wrote:
> > > > On Oct 22, 6:17 am, Chouser <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 22, 2008 at 4:30 AM, Brett Morgan <[EMAIL PROTECTED]> > wrote: > > > > > I understand the lisp way is to use the reader plus macros to interpret > the > > > incoming data stream. This is hella cool in that it seriously cuts down > on > > > the amount of development work I have to do. The reader is already > done, and > > > using macros to build the tree walker? And have them applied to a stm > core? > > > Very lightweight in comparison to what I'd do traditionally. Very cool. > > > > I think that if you use "read" rather than "load" or "eval" on the > > incoming s-expressions, you'll have a lot less to worry about. > > Without the eval step there's no need to try to block arbitrary > > function calls and such, because they'll never be evaluated in the > > first place -- any symbols that match function call names will simply > > be returned from the reader as symbols. > > > > If you then want to call macroexpand on them to help process the > > expressions (I've got no sense of whether this would be a useful > > approach or not) then the only code being run would be your own macro. > > There'd be no way for the incoming s-expressions to define new macros > > or functions. > > > > Perhaps you'd still want to audit the LispReader.java code for > > security vulnerabilities and/or run the reader in some sort of Java > > sandbox, but I wouldn't be surprised if neither of these is actually > > necessary. > > > > --Chouser > > > > This is exactly the suggestion I was going to make. Dealing with > untrusted code doesn't seem to be one of the main design > considerations of Clojure. That I know of, there are no provisions to > keep someone from re-defing existing functions, reaching out of their > current namespace, or jumping into those aspects of Java land that are > available. The safest way to handle data from the client is to keep it > as data and write code to parse and react to it, anything else is > setting up a creativity contest between yourself and anyone trying to > break the application. If companies like Microsoft and Oracle can't > win those with all of their money, a single individual doesn't stand a > chance. > My understanding of the lisp way, and I am but a newbie in the land of lisp, is to deal with untrusted code by writing an meta-circular interpreter for a language that is appropriate for the situation at hand. If you don't trust the people generating the code not re-def functions, take def out of the interpreter. Or leave it in, and have it guard predefined functions. My excitement with clojure is that i get to make lots of dsls really easily, at least in comparison to the heavy engineering approach that is required in the java world... > > -Adam > > > -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
