[SERVER-33896] Profile collection can be created in an non-existent db by applyOps Created: 15/Mar/18  Updated: 27/Oct/23  Resolved: 20/Jun/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Xiangyu Yao (Inactive) Assignee: Ben Judd
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
Operating System: ALL
Steps To Reproduce:

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
Participants:
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.


Generated at Thu Feb 08 04:34:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.