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

Race condition in mongorestore when setting the globalAuthorizationManager

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor - P4
    • Resolution: Fixed
    • Affects Version/s: 2.6.0-rc1
    • Fix Version/s: 2.6.0-rc2
    • Component/s: Security, Tools
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Linked BF Score:
      0

      Description

      Occasionally mongorestore fails to start with the following call stack:

      sh27974| 2014-03-14T15:46:07.210-0400 [journal] Fatal Assertion 16842
      sh27974| 2014-03-14T15:46:07.210-0400 jstests/dur/data/empty.bson
      sh27974| 2014-03-14T15:46:07.210-0400 	going into namespace [test.empty]
      sh27974| 2014-03-14T15:46:07.213-0400 [journal] 0x10068edeb 0x100648712 0x10063827e 0x1000a33cc 0x10010a5f2 0x1001d2502 0x1006c31f5 0x7fff8c9257a2 0x7fff8c9121e1 
      sh27974|  0   mongorestore                        0x000000010068edeb mongo::printStackTrace(std::ostream&)   43
      sh27974|  1   mongorestore                        0x0000000100648712 mongo::logContext(char const*)   114
      sh27974|  2   mongorestore                        0x000000010063827e mongo::fassertFailed(int)   110
      sh27974|  3   mongorestore                        0x00000001000a33cc mongo::getGlobalAuthorizationManager()   28
      sh27974|  4   mongorestore                        0x000000010010a5f2 mongo::Client::initThread(char const*, mongo::AbstractMessagingPort*)   640
      sh27974|  5   mongorestore                        0x00000001001d2502 mongo::dur::durThread()   34
      sh27974|  6   mongorestore                        0x00000001006c31f5 thread_proxy   229
      sh27974|  7   libsystem_c.dylib                   0x00007fff8c9257a2 _pthread_start   327
      sh27974|  8   libsystem_c.dylib                   0x00007fff8c9121e1 thread_start   13
      sh27974| 2014-03-14T15:46:07.214-0400 [journal] 
      sh27974| 
      sh27974| ***aborting after fassert() failure
      sh27974| 

      This is because when the durThread starts it calls client::initThread, which calls getGlobalAuthorizationManager(), which has an fassert that the globalAuthorizationManager is set. In the run method of mongorestore, however, we briefly clear the globalAuthorizationManager to set it to a real implementation instead of a Mock. This leaves a small window where the globalAuthorizationManager is unset, which can trigger the fassert in getGlobalAuthorizationManager depending on the timing of the dur thread starting up.

      Fix is to move the setting of the globalAuthorizationManager out of the Restore class' doRun method and into its constructor, which will run before the durThread is started.

        Attachments

          Activity

            People

            Assignee:
            spencer Spencer Brody (Inactive)
            Reporter:
            kaloian.manassiev Kaloian Manassiev
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: