[SERVER-35323] sessionId matching ignores userId part of the lsid Created: 31/May/18  Updated: 08/Jan/24  Resolved: 11/Oct/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.5
Fix Version/s: 4.0.4, 4.1.4

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
is duplicated by SERVER-36874 Fatal Assertion 40526 while migrating... Closed
Related
related to SERVER-37735 [3.6] Ensure the full logical session... Closed
related to SERVER-44055 All secondary crashed in SessionUpdat... Closed
is related to SERVER-34517 getMore in session while running with... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Sharding 2018-09-24, Sharding 2018-10-22
Participants:
Case:

 Description   

Problem

In the codepath exercised by listCollections and listIndexes on mongos, the userId for a currently authed user is not attached to the command object's LogicalSessionId. This means that the mongod, when receiving the command, will assume the system user (and substitute the system user's id) for its own stored cursor. See Spencer Jackson's comment below for a more detailed explanation.

Proposed Fix

listCollections and listIndexes are the only two callsites for executeCommandAgainstDatabasePrimary. In that function, we possess the cmdObj (has the lsid WITHOUT userID) and the opCtx (has the lsid WITH the userId). Simply add the userId from the opCtx to the cmdObj (Spencer dubs it the mongos "impersonating" the authed user). The cursor will be established with the correct userId. getMores will work with verifying both the sessionId and userId. I have verified this fix to work in a local Evergreen path.



 Comments   
Comment by Kelsey Schubert [ 24/Oct/18 ]

A partial backport of this work is being completed in 3.6 underĀ SERVER-37735.

Comment by Githook User [ 12/Oct/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-35323 Guarantee the command object sent by the ShardingTaskExecutor will always have the correct logical session id

(cherry picked from commit 34de1953a9575f2745a1f430f5eb7ce2a6014031)
Branch: v4.0
https://github.com/mongodb/mongo/commit/f24a83ce6b93aad79ab11c3f7a1eabd998cc111c

Comment by Githook User [ 11/Oct/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-35323 Guarantee the command object sent by the ShardingTaskExecutor will always have the correct logical session id
Branch: master
https://github.com/mongodb/mongo/commit/f2944ecc32d49ecdf801b38653b79e2396a40510

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