Note that there is some discussion on the "math" issue on the gremlin-users mailing list:
https://groups.google.com/d/msg/gremlin-users/EFog3lhh4Xw/1VVi2c9AAAAJ On Wed, Sep 20, 2017 at 11:03 AM, Keith Lohnes <[email protected]> wrote: > I agree with Robert that the scripting-off option would work, but would > have to be the default. I've run into people who aren't particularly happy > about having to `def` variables because we've enabled a sandbox. I think > saying, "These are not enabled by default" in the docs would be a > necessity. Being cut off from a feature like lambdas, I'd imagine I'd be > getting quite a few complaints/support tickets with "Why don't my lambdas > work?" That being said I also try to recommend not using lambdas when I > can. > > Aside from math, I wonder a bit about type conversion and string/array > concatenation also come to mind as things users may be doing that I'm not > aware of a Gremlin specific work around for. > > Overall, I really like the idea as I think it forces the user into a better > mindset about access patterns for their data. I think if there's a > reasonable way to address having the flexibility of lambdas, while offering > the security of GLV only execution, that would be ideal. Either the > restrictive subset of that functionality is allowed or, as Robert > mentioned, making some of these things Gremlin steps, such as a `math` step > that evaluates, `plus`, `minus` etc. steps. Maybe a `cast` step and a > `concat` step. > > -Keith Lohnes > > On Wed, Sep 20, 2017 at 9:21 AM Robert Dale <[email protected]> wrote: > > > Network security is out of scope. It's generally applicable. There's > > nothing peculiar to Gremlin Server that would warrant its own section on > > network security. > > > > I could see where a security-first approach is taken and scripting would > be > > off by default. This forces the user to be somewhat more aware of > opening a > > potential vulnerability vs. "I don't use scripting so I didn't know to > > disable it". > > > > Ideally, many of the functions used in lambdas would become first-class > > citizens in gremlin. Then there is a much higher potential for turning > (or > > leaving) off scripting. > > > > > > Robert Dale > > > > On Wed, Sep 20, 2017 at 8:23 AM, Stephen Mallette <[email protected]> > > wrote: > > > > > It would be an option to turn off script processing, but if you're > saying > > > that you believe that would almost never be possible (as most > production > > > systems will use lambdas) then there probably isn't much point to > adding > > > the option. Scripts will always just be there and users will have to > > > appropriately secure their systems. > > > > > > What patterns do you normally see in the kinds of lambdas you are > > writing? > > > I'm wondering if there were more coarse grained patterns in lambdas > that > > > could be solved with a highly restrictive subset of the scripting > > language. > > > Like a good example of where I tend to get stuck with Gremlin is > "math" - > > > if "math" was a general thing that needed lambdas we could probably > make > > it > > > so that the scriptengine was locked down to only include math > operations. > > > > > > On Tue, Sep 19, 2017 at 3:17 PM, Daniel Kuppitz <[email protected]> > wrote: > > > > > > > > > > > > > Obviously lambdas wouldn't work but that might be fine for many > > > > > applications. > > > > > > > > > > > > I would make a bet that lambdas are used in most production systems. > > > When I > > > > work with customers, I usually try to rewrite queries and prevent the > > use > > > > of lambdas, but often there's simply no way to do the same thing > > without > > > > lambdas without taking a performance hit. So if you're going to make > it > > > an > > > > option in Gremlin Server, cool, but we shouldn't disallow lambdas > > > > altogether. That's probably what you meant, but I thought it might be > > > good > > > > to emphasize it. > > > > > > > > Cheers, > > > > Daniel > > > > > > > > > > > > On Tue, Sep 19, 2017 at 11:05 AM, Stephen Mallette < > > [email protected] > > > > > > > > wrote: > > > > > > > > > I just updated the reference docs for Gremlin Server to include > some > > > more > > > > > wording on security. I just wanted to make it more clear that > Gremlin > > > > > Server executes arbitrary code. I like to think people get that and > > > > > understand the implications of what that means from a security > > > > perspective, > > > > > but.......... > > > > > > > > > > I didn't add much more on "how to secure Gremlin Server" because I > > > think > > > > > what we allow for is pretty much well documented: > > > > > > > > > > 1. Authentication > > > > > 2. Encryption > > > > > 3. Script Execution Management > > > > > > > > > > I feel like there might be a fourth category that involves > discussing > > > how > > > > > to physically protect Gremlin Server with firewall/network stuff, > but > > > I'm > > > > > probably not the best person to write that (or it's simply out of > > scope > > > > for > > > > > our reference docs). If someone else has experience with that sort > of > > > > thing > > > > > and wants to provide advice, a pull request in that area would be > > nice. > > > > > > > > > > I also wonder if we shouldn't allow Gremlin Server to be run > without > > > the > > > > > script execution enabled. In other words, just allow the > > > > > TraversalOpProcessor to execute incoming requests - make it work > in a > > > > > GLV-only mode basically. Obviously lambdas wouldn't work but that > > might > > > > be > > > > > fine for many applications. > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > >
