I don't know why my company block your response, please just respond to my Gmail (I don't talk about confidential component).
If I ask you for a solution, it's not for a gremlin console, we would like to authorize end-user to push on our Gremlin Server their script. We would like to provide for our end user a solution to traverse a graph without any other groovy behavior (Cast, System call, or any malicious code). For the moment we have a workaround to resolve our issue (but we really need this feature). Thanks, Romain. _________________________________________________________________________________________________________________________ SecureASTCustomizer is not a good approach to preventing stuff like that. It has many holes that are easy to get around - you can find lots of examples on the internet if you search around a bit. As of GA, we were using the groovy-sandbox ( http://groovy-sandbox.kohsuke.org/ ) to handle these kinds of security problems, but it's bound to groovy 1.8.x and has some other drawbacks. So - for the future 3.0.1 release, I've looked to do a better job of with this as a whole. For 3.0.1-SNAPSHOT the groovy-sandbox dependency has been removed and includes a revised method for dealing with script security. The core of this development involves plugging in CompilerCustomizer implementations into the ScriptEngine. At a low-level, for TinkerPop purposes, this means, supplying a set of CompilerCustomizerProvider implementations to the GremlinGroovyScriptEngine. These providers construct CompilerCustomizer implementations which handle everything from simple stuff like custom imports to more complex things like script security. For your case, you want to block "while(true){}". In that case, you have a few options but the easiest would be to add TimedInterruptCustomizerProvider to the GremlinGroovyScriptEngine. This will inject a timeout into loops and interrupt them if they run for too long. That's one of the ways that we protect Gremlin Server from malicious scripts that run beyond expected times. I could go into more detail on how all this stuff works, but your concerns are with the Gremlin Console and we don't use CompilerCustomizer implementations there. I've never thought that this was an issue because the Gremlin Console is typically used on a local machine where a user who does "while(true){}" really can only hurt themselves. If they enter "System.exit(0)", they just exit themselves - no one gets hurt. Are you expecting to use the console in some other fashion? Could you explain why you believe this a problem for your implementation? If anything, I might be able to see why this could be a useful general feature of the console itself, but not really something a plugin should worry about. In fact, if this were a plugin capability, it would almost be bad (maybe good??), because a plugin developer could restrict the console such that other graphs/features couldn't be used. Anyway, if you could discuss your use case a bit further, I think that would be helpful. Thanks, Stephen On Tue, Jul 21, 2015 at 8:55 AM, <[email protected]> wrote: > Hello, > > We work on our implementation of tinkerpop 3. I have seen some trouble > during the evaluation of the gremlin script. > > If the end user want to make a "while true" statement it's possible. So we > would like to add SecureASTCustomizer into the evaluation of the script, > but nothing is mention about that. I have some idea, maybe into > implementation of our GremlinPlugin but SecureASTCustomizer is use at > construction of the shell and the only shell provide don't have a way to > modify the configuration. > > Have you provide a solution for my problem ? > > Like you can understand is not acceptable for my company if an end user > can make an infinite loop or some weird thing. > > Regards, > Romain. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
