Hi guys, I don't know how the validations for this are done, but in this case I can think on a naive check for the usage of a banned function. I think a regex can do it. Something that look for* (count\s*+* * I know maybe there are more edges cases but I don't think it'll be much than that. I understand all the sandbox discussion but in this case the question we are trying to answer is: Given the user has found a solution, did he used any banned function?
Sometimes while solving a problem, we can not see simpler solutions. What do you think? Erlis On Fri, Jan 13, 2012 at 11:18 PM, Anthony Grimes <disciplera...@gmail.com>wrote: > I responded to this earlier, but I accidentally hit the 'reply to author' > button instead of 'reply to post', and thus it went directly to Cedric > rather than to the group. I'll respond here and quote the previous emails: > > On Fri, Jan 13, 2012 at 8:57 PM, Anthony Grimes <disciplera...@gmail.com> > wrote: > >> 4Clojure uses clojail for sandboxing behind the scenes. I didn't realize >> that you may not be aware of that. > > > On Friday, January 13, 2012 at 8:12 PM, Cedric Greevey wrote: > >> Indeed I wasn't, and I doubt much of the rest of its user base is either. > > On top of that, the *reason* for this is that it's an implementation > > detail. Implementation details do not excuse incorrect user-visible >> behavior in an application. Figuring out how to make the application >> do what it should, from the user's perspective, and how best to >> implement it to do so is part of the developer's responsibility. > > > Sandboxing is hard. Sacrifices have to be made. This is *not* just an > implementation detail. Users are running their code inside of a sandbox. > This can't be really be hidden. That said, you are absolutely correct. It > is the developer's responsibility to make sure that all of this is as clean > and easy as possible. > > I think Jack's suggestion below is a nice middleground. As a matter of > fact, given a small patch to add a little pre-processing step to clojail > (optional, of course), clojail could even throw a nice error message when a > user tries to use 'for'. How does something like that sound to you? Would > that be an okay compromise? There isn't much more that can be done beyond > actually providing reasonable error messages for these failures. There are > limitations to what can be done. > > On Friday, January 13, 2012 6:44:11 PM UTC-6, Cedric Greevey wrote: > >> On Fri, Jan 13, 2012 at 6:47 PM, Anthony Grimes <discip...@gmail.com> >> wrote: >> > Clojail errs on the side of safety and not on the side of "Oh, well >> maybe he >> > wasn't trying to break the sandbox. Let's allow it anyway.". Treating >> macros >> > as opaque is just another hole in what is already difficult sandboxing. >> > Macros are not even remotely close to functions. They *create* code. >> That >> > code, just like any other explicitly written in your application, needs >> to >> > be sandboxed. It is much easier and safer to sandbox dangerous >> functions. >> > The fact that expanded macro code that uses those functions is also >> affected >> > is less of a bug and more of a feature. >> >> You seem to be confused. We were discussing 4Clojure's rules, where >> the stakes are at worst letting a person "cheat" slightly, not a >> server security system or something, where the stakes would be >> allowing hacking of some sort. Your concern is immensely out of >> proportion to the consequences of someone cheating at 4Clojure's >> learning game. >> >> > That said, of course it is unfortunate that things like this occur in >> > 4Clojure for things as simple as for. But clojail and 4clojure are >> separate >> > projects. clojail is focused on being as safe as possible, which may >> > sometimes clash with what would be most convenient in 4Clojure. >> >> Unclear here is what the two have to do with one another. There's no >> obvious relevance of clojail's requirements for 4Clojure. Indeed, as >> you seem to have realized, the requirements are distinct and sometimes >> would conflict. >> >> -- > 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 > -- 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
