Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-35323

sessionId matching ignores userId part of the lsid

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.6.5
    • Fix Version/s: 4.0.4, 4.1.4
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0, v3.6
    • Sprint:
      Sharding 2018-09-24, Sharding 2018-10-22
    • 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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: