[SERVER-34417] parallelCollectionScan within a session errors under auth Created: 11/Apr/18 Updated: 01/Jun/18 Resolved: 23/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 3.6.3, 3.7.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Andy Schwerin |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
In Perl driver tests, there is a parallel collection scan test that iterates (serially), the cursors returned by parallelCollectionScan. Following the drivers sessions spec, the driver creates an implicit session for this command. When run against a 3.6.3 replica set without authentication, the test passes. When run with authentication enabled, the test fails with this error message:
|
| Comments |
| Comment by Bernie Hackett [ 01/Jun/18 ] | |
|
I think the solution for this in drivers that have a parallelCollectionScan helper that already added a session parameter in 3.6 (e.g. PyMongo) is to not use implicit sessions in the helper. If the application passes an explicit session we'll use it for each cursor. That avoids breaking backward compat and fixes the implicit session problem. If executing the cursors in parallel with the same explicit session is a problem we can add a note to the docs for the helper saying that the cursors have to be executed serially when using a session. | |
| Comment by Shane Harvey [ 23/May/18 ] | |
|
david.golden, when parallel_scan is called with a session, pymongo uses that session for all cursors. This seems to be okay. When parallel_scan is called without a session, pymongo assigns a new session for each resulting cursor. Iterating the cursor with a different session results in an error when auth is enabled. | |
| Comment by David Golden [ 23/May/18 ] | |
|
This back and forth got me curious and I looked at the server commit that Kal referenced. The surprising comment to me was "If the authorization is not on, then we permit anybody to do anything", which led me to dig deeper into the Perl driver code. It turns out there was a bug and the session wasn't being attached properly to the cursor in the parallel scan case. With the bug fixed, serial use of parallel collection scan cursors under auth works in the Perl driver. behackett can you double check pymongo? Looks OK at the wiring up stage, but the test iterates cursors in parallel, which seems dubious when used with sessions, but I can't follow the Python idioms in the test to see for sure what's happening. I apologize for not realizing the bug earlier, but it flips this server ticket around: by NOT validating that a cursor is being iterated on the same session that created it when auth is OFF, the server is exposing different constraint behavior with and without auth. Most driver development/testing is done without auth enabled. Is there a reason why the "no auth" case means "anything goes"? Should we require cursors to iterate on their creator session in all cases for consistency? I also think if parallel scan is not being deprecated, then its use with sessions is going to be a problem eventually anyway once WT supports more than one cursor, since the whole point is to iterate cursors in parallel and thus can't be done on the same session (as sessions must not be used concurrently). I think there's a good argument that parallel scan shouldn't use sessions anyway until we understand the semantics. All that said, I don't think anything here needs to block 4.0. | |
| Comment by Andy Schwerin [ 23/May/18 ] | |
|
The parallelCollectionScan command is fundamentally incompatible with the current conception of sessions. Specifically, sessions were conceived to represent a sequence of actions, and the purpose of parallelCollectionScan is to allow for the parallel execution of many actions. The only reason to reconcile the concept of sessions and the parallelCollectionScan command would be to allow a parallelCollectionScan to execute at snapshot isolation, which is presently only available with the use of sessions. I think that's legitimate future work, but not something that will be quick to fix soon or that can meaningfully backport to 3.6 or 4.0. As such, I'm going to close this ticket "Won't Fix" and I suggest that the drivers make the mentioned by david.golden. | |
| Comment by Kaloian Manassiev [ 23/May/18 ] | |
|
See this comment - the check for sessions matching was introduced by the Platforms team (and I think for a good cause). If this check is not going away, what's there for the sharding team to do to improve parallelCollectionScan? | |
| Comment by Kaloian Manassiev [ 09/May/18 ] | |
|
The check that cursors must be iterated on the same session as the one which created them was introduced in 3.6 in this commit as part of Given that the parallelCollectionScan and MMAPv1 are deprecated, I suspect that this will not be fixed and that users of parallelCollectionScan must be required to so without using sessions. Passing this on to the Platforms team to decide what to do with it. | |
| Comment by Spencer Brody (Inactive) [ 17/Apr/18 ] | |
|
FYI ian.whalen david.storch since I believe query owns parallelCollectionScan | |
| Comment by Gregory McKeon (Inactive) [ 16/Apr/18 ] | |
|
Sending to sharding because it's sessions. | |
| Comment by Bernie Hackett [ 11/Apr/18 ] | |
|
I'm seeing a very similar problem. In my case the error only occurs against MongoDB master running with MMAPv1:
|