[SERVER-35192] Enforce that GETMORE operations can only be run under that cursor's session even without auth Created: 23/May/18  Updated: 06/Dec/22  Resolved: 20/Nov/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.6.5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Golden Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-34417 parallelCollectionScan within a sessi... Closed
related to SERVER-28343 Enforce that GETMORE operations can o... Closed
Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

SERVER-28343 enforced that a cursor can only be iterated under the session that created it, but only applied that restriction if auth is turned on. This led to some surprising behavior detailed in SERVER-34417.

For consistency between auth and no-auth cases, cursors should always require the same session, regardless of whether auth is enabled.



 Comments   
Comment by Craig Homa [ 20/Nov/18 ]

This has been fixed this in 4.0+, it is unclear what the value of fixing this in 3.6 would be.

Please let us know if you have any questions.

Comment by David Golden [ 24/Jul/18 ]

I believe this is still an issue. In the code path that (erroneously) sent getmore without a session ID, it succeeded in 3.6.5 with auth disabled and gave an error on 4.0.0-rc0 (with auth disabled). I believe that with auth enabled, 3.6.5 would error just like 4.0.0. This ticket requests that noauth 3.6 have the same constraints as auth 3.6.

Comment by Asya Kamsky [ 24/Jul/18 ]

david.golden can you help me understand the likelihood of this being an issue in 3.6?

 

Comment by Asya Kamsky [ 12/Jun/18 ]

Is parallelCollectionScan integral to creating the situation where this scenario happens?
I'm trying to assess the likelihood and impact of this.

Or is this any scenario where in 3.6 (and only when auth is off) you can run a query/establish a cursor from one session and then send a GETMORE for the same cursor from a different session/no session?

Comment by David Golden [ 23/May/18 ]

The Perl bug I found in SERVER-34417 created a cursor (via parallelCollectionScan) with a sessionID, but sent getmore without a session ID. That ran fine without auth, and only failed with auth. That was on a v3.6.3 replica set. I just tested it on v4.0.0-rc0 and it does error without auth, with the error message in that commit you linked.

That's good to know, but a comparable fix also should be made for 3.6.

I doubled checked v3.6.5 and the test that failed with an error on v4.0.0-rc0 (without auth), succeeded on v3.6.5 (without auth).

Comment by Kaloian Manassiev [ 23/May/18 ]

Isn't this already in place - https://github.com/mongodb/mongo/blob/e4e2162c489c1faa569463f51058ebc09368a5f9/src/mongo/db/commands/getmore_cmd.cpp#L77 ?

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