[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:
Duplicate
is duplicated by SERVER-34525 lsid error on getMore when a new sess... Closed
Related
related to SERVER-33998 Remove the parallelCollectionScan com... Closed
is related to PYTHON-1529 parallel_scan with implicit session e... Closed
is related to SERVER-35192 Enforce that GETMORE operations can o... Closed
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:

Cursor session id (f02e04ea-a996-40de-afa5-b71477649231 - Y5mrDaxi8gv8RmdTsQ+1j7fmkr7JUsabhNmXAheU0fg=) is not the same as the operation context's session id (none)



 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 SERVER-28343. It looks like this behaviour is intentional.

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:

[2018/04/10 18:21:20.972] OperationFailure: Cannot run getMore on cursor 5301017319798, which was created in session 67677af3-85fd-499c-8763-e7240b5b2340 - 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=, in session 28959612-948a-438b-92e5-20e41b091234 - 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

https://evergreen.mongodb.com/task/mongo_python_driver_tests_storage_engines__python_version~2.7_storage_engine~mmapv1_test_latest_standalone_04de1697cb1f1d877023942f7ce620415ee08b60_18_04_10_00_04_15

Generated at Thu Feb 08 04:36:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.