If I may :) since I'm the sandbox guy. On May 6, 2010, at 18:18 , Mibu wrote:
> I mentioned in the first message that javaop should also be disabled > in a restricted eval. > > On May 6, 5:18 pm, gary ng <garyng2...@gmail.com> wrote: >> On Thu, May 6, 2010 at 4:19 AM, Mibu <mibu.cloj...@gmail.com> wrote: >>> As far as I can tell, clj-sandbox works by a set whitelist of >>> arbitrary functions, which is not a very generic approach. It works >>> for sandboxes like clojurebot, but not for other stuff. I place the bold claim clj-sandbox is pretty good for 'other stuff'. Let me explain. >> >>> A restricted eval in all likelihood will not refer directly to >>> clojure.core, and it's much better allowing the caller to specify by >>> namespaces which functions are accessible. Exactly that is what clj-sandbox does. It just comes which a list of things that we consider secure. clj-sandbox allows a very fine grained customization of the rules it. It not even has a multitude of 'testers' including for things as namespaces, classes and functions but even has a pretty simple interface to write custom tests that could, for example restrict the usage of let on every other tuesday without any adjustment to the sandbox itself. >>> Maybe in the future >>> clojure.core functions could be tagged depending on whether they are >>> purely-functional or have side-effects, and a caller to a restricted >>> eval will be able to automatically generate a new "safe-core" >>> namespace based on this division. When that happens there will of cause be a clj-sandbox tester to easily match against those functions! >> >> While we are talking about sandboxed eval, it is not just which function is >> accessible but also things like .alterRoot which becomes a instance method >> of a java object which goes a bit beyond clojure name space. with some >> clever tricks, it is possible to get the var of a root binding then >> .alterRoot and replace the definition. This is very true, there clj-sandbox takes a rather elaborated approach to make it hard to do this and succeeds quite well. It goes so far to replace the . function in the code against a custom version to make sure things like .alterRoot can't ever be called, and trust me ato_ has made us quite a headache with this :P. In addition to that it also supports java sand-boxing (they have this nifty thing) but this is something the user has to explore into themselves. Mibu, if you are interested in this kind of stuff I'll gladly help you to use clj-sandbox for your issue since I am pretty confident it can solve your problem and if it can't it should and we'll work on making it ;) Regards, Licenser - the sandbox guy. -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
