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

Profile collection can be created in an non-existent db by applyOps

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Gone away
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Storage
    • Labels:
      None
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      1.Go to commit 855320ba664efb2f80123ef66cc78617bb34dfc1 of v3.6
      2.Run standalone server and set profile level of testDb to be 2

      db.setProfilingLevel(2)
      

      3.Run command:

      assert.commandWorked(db.runCommand({
              applyOps: [
                  {
                      op: 'c',
                      ns: 'test.$cmd',
                      o: {
                          renameCollection: 'test.testColl',
                          to: 'test.renamedColl',
                          stayTemp: false,
                          dropTarget: false
                      }
                  },
                  {
                      op: 'c',
                      ns: 'test.$cmd',
                      o: {
                          renameCollection: 'jstests/concurrency/fsm_workloads',
                          to: 'test.123',
                          stayTemp: false,
                          dropTarget: false
                      }
                  }
              ]
          }));
      

      4. Now you can see a db called "jstests/concurrency/fsm_workloads" and a collection "jstests/concurrency/fsm_workloads.system.profile"!

      > show dbs
      admin                              0.000GB
      jstests/concurrency/fsm_workloads  0.000GB
      local                              0.000GB
      test                               0.000GB
      

      This bug is only exposed in the given commit because a later commit changes the codepath which this command would take. This is still a bug, however, because other commands could end up taking the original codepath"

      Show
      1.Go to commit 855320ba664efb2f80123ef66cc78617bb34dfc1 of v3.6 2.Run standalone server and set profile level of testDb to be 2 db.setProfilingLevel(2) 3.Run command: assert.commandWorked(db.runCommand({ applyOps: [ { op: 'c', ns: 'test.$cmd', o: { renameCollection: 'test.testColl', to: 'test.renamedColl', stayTemp: false, dropTarget: false } }, { op: 'c', ns: 'test.$cmd', o: { renameCollection: 'jstests/concurrency/fsm_workloads', to: 'test.123', stayTemp: false, dropTarget: false } } ] })); 4. Now you can see a db called "jstests/concurrency/fsm_workloads" and a collection "jstests/concurrency/fsm_workloads.system.profile"! > show dbs admin 0.000GB jstests/concurrency/fsm_workloads 0.000GB local 0.000GB test 0.000GB This bug is only exposed in the given commit because a later commit changes the codepath which this command would take. This is still a bug, however, because other commands could end up taking the original codepath"
    • Sprint:
      Storage NYC 2018-06-18, Storage NYC 2018-07-02
    • Linked BF Score:
      0

      Description

      If there are multiple oplog entries in the applyOps command, the profiling level of the db in the later entries will be set to the highest profiling level of the db in the previous entries because of https://github.com/mongodb/mongo/blob/0109767b6962d18b60d89a723c0087cf27d370e3/src/mongo/db/curop.cpp#L273.

      This bug caused BF-8147. Although our current code base of renameCollection (only v3.6 was tested) won't trigger the code path that caused this bug, there could be other commands that trigger it.

        Attachments

          Activity

            People

            Assignee:
            ben.judd Ben Judd
            Reporter:
            xiangyu.yao Xiangyu Yao (Inactive)
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: