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

authSchemaUpgradeStep could handle invalid users better

      If you have an invalid user document in admin.system.users (I've only run this in a sharded environment), you start getting some very unhelpful errors. I get the below errors when I manually insert

      { a : 1 }

      into admin.system.users on mongos before running authSchemaUpgradeStep:

      m30999| 2013-12-16T12:04:29.404-0500 [conn1] Auth schema upgrade processing schema version 1 users from database test
      m29000| 2013-12-16T12:04:29.404-0500 [conn7] end connection 127.0.0.1:51136 (5 connections now open)
      m30999| 2013-12-16T12:04:29.404-0500 [conn1] Assertion: 13111:field not found, expected type 2
      m30999| 2013-12-16T12:04:29.409-0500 [conn1] 0x10042569b 0x1003e29a2 0x1003d039f 0x1003d047d 0x1002b6460 0x10009a836 0x10003a063 0x10002d378 0x10002c8a7 0x1000b68c9 0x10009d25b 0x100111bd0 0x10033839b 0x1002d7f68 0x100358aed 0x100337a27 0x100002d9f 0x1003eac11 0x1004559c5 0x7fff8c3e8772
      m30999| 0 mongos-26 0x000000010042569b _ZN5mongo15printStackTraceERSo + 43
      m30999| 1 mongos-26 0x00000001003e29a2 _ZN5mongo10logContextEPKc + 114
      m30999| 2 mongos-26 0x00000001003d039f _ZN5mongo11msgassertedEiPKc + 255
      m30999| 3 mongos-26 0x00000001003d047d _ZN5mongo11msgassertedEiRKSs + 29
      m30999| 4 mongos-26 0x00000001002b6460 _ZNK5mongo11BSONElement3chkEi + 800
      m30999| 5 mongos-26 0x000000010009a836 ZN5mongo12_GLOBAL_N_118upgradeProcessUserEPNS_25AuthzManagerExternalStateERKNS_10StringDataERKNS_7BSONObjES8_ + 374
      m30999| 6 mongos-26 0x000000010003a063 _ZN5mongo20DBClientFunConvertorclERNS_27DBClientCursorBatchIteratorE + 231
      m30999| 7 mongos-26 0x000000010002d378 _ZN5mongo18DBClientConnection5queryEN5boost8functionIFvRNS_27DBClientCursorBatchIteratorEEEERKSsNS_5QueryEPKNS_7BSONObjEi + 686
      m30999| 8 mongos-26 0x000000010002c8a7 _ZN5mongo12DBClientBase5queryEN5boost8functionIFvRKNS_7BSONObjEEEERKSsNS_5QueryEPS4_i + 397
      m30999| 9 mongos-26 0x00000001000b68c9 _ZN5mongo31AuthzManagerExternalStateMongos5queryERKNS_15NamespaceStringERKNS_7BSONObjES6_RKN5boost8functionIFvS6_EEE + 429
      m30999| 10 mongos-26 0x000000010009d25b _ZN5mongo20AuthorizationManager17upgradeSchemaStepERKNS_7BSONObjEPb + 3035
      m30999| 11 mongos-26 0x0000000100111bd0 _ZN5mongo24CmdAuthSchemaUpgradeStep3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb + 290
      m30999| 12 mongos-26 0x000000010033839b _ZN5mongo7Command22execCommandClientBasicEPS0_RNS_11ClientBasicEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb + 681
      m30999| 13 mongos-26 0x00000001002d7f68 _ZN5mongo7Command20runAgainstRegisteredEPKcRNS_7BSONObjERNS_14BSONObjBuilderEi + 678
      m30999| 14 mongos-26 0x0000000100358aed _ZN5mongo14SingleStrategy7queryOpERNS_7RequestE + 1851
      m30999| 15 mongos-26 0x0000000100337a27 _ZN5mongo7Request7processEi + 1249
      m30999| 16 mongos-26 0x0000000100002d9f _ZN5mongo21ShardedMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE + 141
      m30999| 17 mongos-26 0x00000001003eac11 _ZN5mongo17PortMessageServer17handleIncomingMsgEPv + 1681
      m30999| 18 mongos-26 0x00000001004559c5 thread_proxy + 229
      m30999| 19 libsystem_c.dylib 0x00007fff8c3e8772 _pthread_start + 327
      m30000| 2013-12-16T12:04:29.409-0500 [conn2] end connection 127.0.0.1:51123 (4 connections now open)
      m30999| 2013-12-16T12:04:29.409-0500 [conn1] Detected bad connection created at 1387213466016787 microSec, clearing pool for localhost:30000 of 0 connections
      m30999| 2013-12-16T12:04:29.409-0500 [conn1] Auth schema upgraded failed with Unknown error code field not found, expected type 2
      m30999| 2013-12-16T12:04:29.409-0500 [conn1] distributed lock 'authorizationData/specter.local:30999:1387213466:16807' unlocked.

      { "ok" : 0, "errmsg" : "field not found, expected type 2", "code" : 13111 }

      I'm not sure what the correct behavior here is. I'd imagine there are two possible options:

      1) Ignore invalid user documents and only upgrade valid ones, perhaps logging an error when there's a bad document.
      2) Fail.

      We seem to do #2, which is perfectly valid, but it would help if the error message included something like the contents of the invalid user doc.

            Assignee:
            spencer@mongodb.com Spencer Brody (Inactive)
            Reporter:
            valeri.karpov@mongodb.com Valeri Karpov
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: