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

killCursors potential race/ABA problem

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Querying
    • Query Execution
    • ALL

    Description

      The killCursors command works by:
      1) Pinning the cursor to be deleted
      2) Checking auth
      3) Unpinning the cursor
      4) Locking the partition of the cursorMap that contains the cursor
      5) Destroying it

      It seems like there could be an ABA problem here. Say user X tries to destroy the cursor C. The server receives the command and the auth check passes (step 2). Then, between steps 3 and 4, the cursor is exhausted and cleaned up. User Y then creates a cursor on the same collection and happens to get the same cursor id as C. Step 4 of user X's killCursors command now runs, and at step 5, kills the cursor with id C (which is user Y's cursor!).

      It seems like the best way to go is to just perform the authentication check as part of the run() portion of the command to avoid the double-locking we currently do. The getMore command does something similar.

      Note that the changes from SERVER-21710 might make this problem a bit harder to solve since we'll be able to kill cursors while they're pinned, so the authCheck will have to hold the lock on the cursorMap partition which has the cursor.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated: