Access controls for vertices, edges and vertex properties
Hello Apologies if this is the incorrect forum - I was pointed here from another mailing list. I had an idea for an access control scheme that could be applied to vertices, edges or vertex properties and would allow a server to check whether a user has permission to retrieve or traverse that particular graph element. The access control property would be a set of rules outlining the attributes, and the combination of those attributes, that establish whether or not a user has sufficient privileges for that graph element. I have experimented with attempting to use the existing Gremlin language to do this, but I have so far been unable to achieve the level of fine-grained access control that I believe would be useful in a variety of situations. I have tested this with a prototype that uses a Java object and a custom predicate that tests a user's profile against the access control, and then used a traversal strategy to constrain a query to those elements which pass the test. I was curious as to whether people would see such a feature as something that could be part of Gremlin, or whether it would be better left to specific implementations of Tinkerpop. Thanks for your consideration.
[DISCUSS] Rename release branches
While we've stuck to the pattern of naming our release branches as "tp" as in: tp33 = 3.3.x I think we should consider renaming to something more recognizable - perhaps: 3.3-dev = 3.3.x which I think does two things: 1. pushes the the development branches to the top of the dropdown in github above all the JIRA feature branches 2. hopefully allows new contributors to realize that we have other lines of development (more so than we do now at any rate) The main impact that I can think of is that all existing PRs would need to be retargetted. That's mostly a concern for older PRs that have been hanging around forever (which should probably be closed anyway). I think that if we go this route I'll either close, re-target or if a third-party PR that's gone orphan but still has value I'll pull it to a branch of our own and hold it there. Is there other impact to consider? Assuming no objections or worries I'm not considering right now, I'll proceed with this change next week.
[jira] [Commented] (TINKERPOP-2262) Improve Netty protocol handling
[ https://issues.apache.org/jira/browse/TINKERPOP-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006951#comment-17006951 ] ASF GitHub Bot commented on TINKERPOP-2262: --- spmallette commented on pull request #1232: TINKERPOP-2262 Prevented channel close by server on protocol error URL: https://github.com/apache/tinkerpop/pull/1232 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve Netty protocol handling > --- > > Key: TINKERPOP-2262 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2262 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.3.7, 3.4.2 >Reporter: Divij Vaidya >Priority: Major > > 4.1.37 adds [https://github.com/netty/netty/pull/9116] which is critical to > the stability of the Java Client. > After the upgrade a follow-up task would : > 1. change the Java Client to set the newly introduced flag > "closeOnProtocolViolation" to false. This would prevent causing all the other > requests using the same channel to fail when a single request causes a > protocol violation. > 2. introduce the protocol exception error handling code on the client to > handle protocol violation exceptions. Currently, the code force replaces the > channel, thus closing all the other requests being served on the channel.[ > https://netty.io/news/2019/06/28/4-1-37-Final.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2262) Improve Netty protocol handling
[ https://issues.apache.org/jira/browse/TINKERPOP-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2262. --- Fix Version/s: 3.4.5 3.5.0 Assignee: Stephen Mallette Resolution: Done > Improve Netty protocol handling > --- > > Key: TINKERPOP-2262 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2262 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.3.7, 3.4.2 >Reporter: Divij Vaidya >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.5.0, 3.4.5 > > > 4.1.37 adds [https://github.com/netty/netty/pull/9116] which is critical to > the stability of the Java Client. > After the upgrade a follow-up task would : > 1. change the Java Client to set the newly introduced flag > "closeOnProtocolViolation" to false. This would prevent causing all the other > requests using the same channel to fail when a single request causes a > protocol violation. > 2. introduce the protocol exception error handling code on the client to > handle protocol violation exceptions. Currently, the code force replaces the > channel, thus closing all the other requests being served on the channel.[ > https://netty.io/news/2019/06/28/4-1-37-Final.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [tinkerpop] spmallette closed pull request #1231: TINKERPOP-2266 Start keep alive polling on Connection construction
[ pull request closed by spmallette ] [ Full content available at: https://github.com/apache/tinkerpop/pull/1231 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Closed] (TINKERPOP-2266) Keep alive not started at connection creation
[ https://issues.apache.org/jira/browse/TINKERPOP-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2266. --- Fix Version/s: 3.3.10 3.4.5 3.5.0 Assignee: Stephen Mallette Resolution: Fixed > Keep alive not started at connection creation > - > > Key: TINKERPOP-2266 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2266 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.3.5 >Reporter: Christian Howe >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.5.0, 3.4.5, 3.3.10 > > > I keep seeing connections in the connection pool being closed in the Gremlin > Java driver, and it looks like there are no keep alive messages being sent to > keep the connection open. However, after a write happens to the connection, > the keep alive seems to start and keep the connection open, based on > observations from tcpdump. The problem with this is that sometimes when we > make a query to the client, we get a connection which is closed, and an > exception is thrown. This results in an increase in customer-impacting > faults, and retries are likely to pull down another connection which is also > closed in a pool with a lot of connections. Larger pools are necessary with > longer running queries to have sufficient concurrency. > It looks like [when keep alive was > added|https://github.com/apache/tinkerpop/pull/433], it was written to only > start the keep alive after there is a write to the connection. In the case > where a connection is created as part of a connection pool during > initialization, I can't find where any write would be made to start the keep > alive. Is there another a mechanism to start this keep alive when a > connection is created? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2266) Keep alive not started at connection creation
[ https://issues.apache.org/jira/browse/TINKERPOP-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006957#comment-17006957 ] ASF GitHub Bot commented on TINKERPOP-2266: --- spmallette commented on pull request #1231: TINKERPOP-2266 Start keep alive polling on Connection construction URL: https://github.com/apache/tinkerpop/pull/1231 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Keep alive not started at connection creation > - > > Key: TINKERPOP-2266 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2266 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.3.5 >Reporter: Christian Howe >Priority: Major > > I keep seeing connections in the connection pool being closed in the Gremlin > Java driver, and it looks like there are no keep alive messages being sent to > keep the connection open. However, after a write happens to the connection, > the keep alive seems to start and keep the connection open, based on > observations from tcpdump. The problem with this is that sometimes when we > make a query to the client, we get a connection which is closed, and an > exception is thrown. This results in an increase in customer-impacting > faults, and retries are likely to pull down another connection which is also > closed in a pool with a lot of connections. Larger pools are necessary with > longer running queries to have sufficient concurrency. > It looks like [when keep alive was > added|https://github.com/apache/tinkerpop/pull/433], it was written to only > start the keep alive after there is a write to the connection. In the case > where a connection is created as part of a connection pool during > initialization, I can't find where any write would be made to start the keep > alive. Is there another a mechanism to start this keep alive when a > connection is created? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2315) Implement some form of clone() or reset() for Traversal in GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006974#comment-17006974
]
ASF GitHub Bot commented on TINKERPOP-2315:
---
spmallette commented on pull request #1233: TINKERPOP-2315 Implement clone()
for all GLVs
URL: https://github.com/apache/tinkerpop/pull/1233
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Implement some form of clone() or reset() for Traversal in GLVs
> ---
>
> Key: TINKERPOP-2315
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2315
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, javascript, python
>Affects Versions: 3.3.9
>Reporter: Stephen Mallette
>Priority: Major
>
> There doesn't seem to be a method to do what we do in Java fairly often:
> {code}
> attached = g.V().hasLabel('OID').out('attached')
> assert attached.clone().count().next() == 4
> uids = attached.clone().dedup().toList()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2315) Implement some form of clone() or reset() for Traversal in GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2315.
---
Fix Version/s: 3.3.10
3.4.5
3.5.0
Assignee: Stephen Mallette
Resolution: Done
> Implement some form of clone() or reset() for Traversal in GLVs
> ---
>
> Key: TINKERPOP-2315
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2315
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, javascript, python
>Affects Versions: 3.3.9
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.5.0, 3.4.5, 3.3.10
>
>
> There doesn't seem to be a method to do what we do in Java fairly often:
> {code}
> attached = g.V().hasLabel('OID').out('attached')
> assert attached.clone().count().next() == 4
> uids = attached.clone().dedup().toList()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [tinkerpop] spmallette closed pull request #1234: TINKERPOP-2175 Better manage the executor thread on close.
[ pull request closed by spmallette ] [ Full content available at: https://github.com/apache/tinkerpop/pull/1234 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2175) Executor thread is not returned on channel close
[ https://issues.apache.org/jira/browse/TINKERPOP-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006978#comment-17006978 ] ASF GitHub Bot commented on TINKERPOP-2175: --- spmallette commented on pull request #1234: TINKERPOP-2175 Better manage the executor thread on close. URL: https://github.com/apache/tinkerpop/pull/1234 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Executor thread is not returned on channel close > > > Key: TINKERPOP-2175 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2175 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.4.0, 3.3.5 >Reporter: Divij Vaidya >Priority: Major > > This issue was originally discussed in > https://issues.apache.org/jira/browse/TINKERPOP-2169 > Due to an error (such as CorruptedFrameException) a client might decide to > close the Netty channel to the server with a CloseWebsocketFrame. On the > server, although the channel gets closed, there might be some executor > threads waiting for watermark to clear which will not clear in these cases > since client has already given up on these requests. This leads to these > executors waiting for the client to consume results till the timeout. > A simple fix would be to check for channel.isActive() while waiting for > channel to become writable at [1] and [2]. > > [1][https://github.com/apache/tinkerpop/blob/d1a3fa147d1f009ae57274827c9b59426dfc6e58/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L533] > > [2][https://github.com/apache/tinkerpop/blob/d1a3fa147d1f009ae57274827c9b59426dfc6e58/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/AbstractOpProcessor.java#L141] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2175) Executor thread is not returned on channel close
[ https://issues.apache.org/jira/browse/TINKERPOP-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2175. --- Fix Version/s: 3.3.10 3.4.5 3.5.0 Assignee: Stephen Mallette Resolution: Fixed > Executor thread is not returned on channel close > > > Key: TINKERPOP-2175 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2175 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.4.0, 3.3.5 >Reporter: Divij Vaidya >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.5.0, 3.4.5, 3.3.10 > > > This issue was originally discussed in > https://issues.apache.org/jira/browse/TINKERPOP-2169 > Due to an error (such as CorruptedFrameException) a client might decide to > close the Netty channel to the server with a CloseWebsocketFrame. On the > server, although the channel gets closed, there might be some executor > threads waiting for watermark to clear which will not clear in these cases > since client has already given up on these requests. This leads to these > executors waiting for the client to consume results till the timeout. > A simple fix would be to check for channel.isActive() while waiting for > channel to become writable at [1] and [2]. > > [1][https://github.com/apache/tinkerpop/blob/d1a3fa147d1f009ae57274827c9b59426dfc6e58/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L533] > > [2][https://github.com/apache/tinkerpop/blob/d1a3fa147d1f009ae57274827c9b59426dfc6e58/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/AbstractOpProcessor.java#L141] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [tinkerpop] spmallette closed pull request #1235: TINKERPOP-2320 allow to pass custom XmlInputFactory when instantiating GraphMLReader
[ pull request closed by spmallette ] [ Full content available at: https://github.com/apache/tinkerpop/pull/1235 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Closed] (TINKERPOP-2320) [SECURITY] XMLInputFactory initialization in GraphMLReader introduces
[
https://issues.apache.org/jira/browse/TINKERPOP-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2320.
---
Fix Version/s: 3.3.10
3.4.5
3.5.0
Assignee: Stephen Mallette
Resolution: Done
> [SECURITY] XMLInputFactory initialization in GraphMLReader introduces
> --
>
> Key: TINKERPOP-2320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2320
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.4
>Reporter: Norio Akagi
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.5.0, 3.4.5, 3.3.10
>
>
> I use TinkerPop in my company and now the security team had audits and
> reported that this part in GraphML reader may introduce XXE vulnerabilities.
> {{private final XMLInputFactory inputFactory =
> XMLInputFactory.newInstance();}}
> Some document recommends to add some properties to protect it as follows:
> [https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#xmlinputfactory-a-stax-parser]
> So I am wondering if I can either
> 1. just hard-code to set these properties in the constructor of GraphMLReader
> (it will break the existing behavior if users use it)
> 2. somehow make these properties configurable so that we can pass some flags
> and depending on the flags, we initialize GraphMLReader with those properties.
> Any recommendation ? I am happy to add implementation to handle it but need
> some input which direction I'd take.
> Thanks.
> Norio
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2320) [SECURITY] XMLInputFactory initialization in GraphMLReader introduces
[
https://issues.apache.org/jira/browse/TINKERPOP-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006981#comment-17006981
]
ASF GitHub Bot commented on TINKERPOP-2320:
---
spmallette commented on pull request #1235: TINKERPOP-2320 allow to pass custom
XmlInputFactory when instantiating GraphMLReader
URL: https://github.com/apache/tinkerpop/pull/1235
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [SECURITY] XMLInputFactory initialization in GraphMLReader introduces
> --
>
> Key: TINKERPOP-2320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2320
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.4
>Reporter: Norio Akagi
>Priority: Major
>
> I use TinkerPop in my company and now the security team had audits and
> reported that this part in GraphML reader may introduce XXE vulnerabilities.
> {{private final XMLInputFactory inputFactory =
> XMLInputFactory.newInstance();}}
> Some document recommends to add some properties to protect it as follows:
> [https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#xmlinputfactory-a-stax-parser]
> So I am wondering if I can either
> 1. just hard-code to set these properties in the constructor of GraphMLReader
> (it will break the existing behavior if users use it)
> 2. somehow make these properties configurable so that we can pass some flags
> and depending on the flags, we initialize GraphMLReader with those properties.
> Any recommendation ? I am happy to add implementation to handle it but need
> some input which direction I'd take.
> Thanks.
> Norio
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
