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 <robd...@gmail.com> 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 <spmalle...@gmail.com> > 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 <m...@gremlin.guru> 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 < > spmalle...@gmail.com > > > > > > 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? > > > > > > > > > >
