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.
>
>
