[SERVER-14994] Cannot drop system.* collections not in admin db Created: 21/Aug/14  Updated: 16/Mar/23

Status: Open
Project: Core Server
Component/s: Usability
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Rod Adams Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Assigned Teams:
Server Security
Operating System: ALL
Sprint: Platforms 2017-01-23
Participants:
Linked BF Score: 0

 Description   

It appears that in 2.6, while making the system.* collections harder to work directly with things seem to have gotten perhaps a bit too overzealous.

In particular, should someone have a collection names system.users in a database other than admin, it is effectively useless, yet a source of great confusion to some.

From https://github.com/mongodb/mongo/blame/562c8cb3faff5e9fc0acdc45db8dc2d498eb2000/src/mongo/db/catalog/database.cpp#L342 it would make sense for s.isSystem() to check if it's in the admin database or not.

Repro:

  • make a table called system.users in any database but admin.
  • attempt to delete it.
  • fail
  • give yourself __system role.
  • still fail.


 Comments   
Comment by Spencer Jackson [ 25/Jan/17 ]

I can confirm this behavior still exists in 3.4.

With auth:

MongoDB Enterprise > use admin
switched to db admin
MongoDB Enterprise > db.createUser({user: "admin", pwd: "admin", roles: ["root"]})
Successfully added user: { "user" : "admin", "roles" : [ "root" ] }
MongoDB Enterprise > db.auth("admin", "admin")
1
MongoDB Enterprise > use test
switched to db test
MongoDB Enterprise > db.system.users.insert({data: 5})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise > db.system.users.drop()
2017-01-25T15:21:34.390-0500 E QUERY    [thread1] Error: drop failed: {
        "ns" : "test.system.users",
        "ok" : 0,
        "errmsg" : "can't drop system collection test.system.users",
        "code" : 20,
        "codeName" : "IllegalOperation"
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DBCollection.prototype.drop@src/mongo/shell/collection.js:752:1
@(shell):1:1
MongoDB Enterprise >

Now that we've migrated away from the 2.4 user schema, it would be very easy to prevent this collection from being creatable in userAllowedCreateNS.

But we should definitely be able to delete some non-admin system collections.
For example,

MongoDB Enterprise > db.system.js.drop()
2017-01-25T15:26:37.927-0500 E QUERY    [thread1] Error: drop failed: {
        "ns" : "test.system.js",
        "ok" : 0,
        "errmsg" : "can't drop system collection test.system.js",
        "code" : 20,
        "codeName" : "IllegalOperation"
} :

Administrators are encouraged to create this collection themselves in the docs. We'll need to be a bit careful as we do this, to make sure that we don't open things too wide.

Comment by Sean Hyrich (Inactive) [ 12/Oct/14 ]

The legacy system.users collections leftover after a 2.4 -> 2.6 upgrade are causing headaches for copyDatabase() as well. A custom role granting find privileges on system.users needs to be created in the "from" database and then granted to the user doing the copy in order for a user to able to read the system.users collection, otherwise the copy fails with:

{ 
"errmsg" : "exception: nextSafe(): { $err: \"not authorized for query on DATABASE_NAME.system.users\", code: 13 }", 
"code" : 13106, 
"ok" : 0 
}

Generated at Thu Feb 08 03:36:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.