[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: |
|
||||||||
| 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:
|
| Comments |
| Comment by Spencer Jackson [ 25/Jan/17 ] | ||||||||||||||||||||||||||||||
|
I can confirm this behavior still exists in 3.4. With auth:
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.
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:
|