[SERVER-13647] root role does not contain sufficient privileges for a mongorestore of a system with security enabled Created: 17/Apr/14  Updated: 22/Mar/17  Resolved: 26/Aug/15

Status: Closed
Project: Core Server
Component/s: Security, Tools
Affects Version/s: 2.6.0, 3.0.4
Fix Version/s: 3.0.7, 3.1.8

Type: Bug Priority: Major - P3
Reporter: Dharshan Rangegowda Assignee: Merry Mou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File core.13738    
Issue Links:
Documented
is documented by DOCS-6310 3.0.7 update to root role Closed
Related
is related to DOCS-3233 Clarify that the "root" role does not... Closed
is related to TOOLS-770 Mongodump/mongorestore should warn if... Accepted
is related to TOOLS-760 can't restore users Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Sprint: Security 7 08/10/15, Security 8 08/28/15
Participants:

 Description   

The "root" role is lacking several privileges present in "restore" role, such as the ability to insert directly into the system.users, system.roles, and system.version collections. These privileges are necessary to be able to use mongorestore to restore a system with authorization enabled, however granting them to the "root" role is also potentially problematic as it would allow users with the "root" role to manipulate admin.system.users, bypassing the safety checks present in the user management commands.

If you try to use the "root" role to do a mongorestore when the dump contains system.users, system.roles or system.version entries, you will get an error like the following:

mongorestore -u admin -p <pass> --drop -h 127.0.0.1:27017 "/mongodb_data_bak/backup"
connected to: 127.0.0.1:27017
2014-04-17T20:44:54.647+0000 going into namespace [admin.system.version]
Restoring to admin.system.version without dropping. Restored data will be inserted without raising errors; check your server log
1 objects found
2014-04-17T20:44:54.648+0000 Creating index: { key:

{ _id: 1 }

, name: "id", ns: "admin.system.version" }
Error creating index admin.system.version: 13 err: "not authorized to create index on admin.system.version"
Aborted (core dumped)



 Comments   
Comment by Githook User [ 31/Aug/15 ]

Author:

{u'name': u'Merry Mou', u'email': u'merry.mou@mongodb.com'}

Message: SERVER-13647 give restore privileges to root
Branch: v3.0
https://github.com/mongodb/mongo/commit/59ec1ed062e13ff77a17f4a3480bcd0f98e38efc

Comment by Githook User [ 21/Aug/15 ]

Author:

{u'name': u'Merry Mou', u'email': u'merry.mou@mongodb.com'}

Message: SERVER-13647 give restore privileges to root
Branch: master
https://github.com/mongodb/mongo/commit/0c695aa1e879af482dc3aea4768dbda223ff4592

Comment by Kay Agahd [ 17/Jun/15 ]

spencer it's great to hear that restore privileges are granted to the root role! Also, "make mongorestore warn if it is restoring old-style user documents that will be ignored by a current version of mongodb" helps the user to understand what happened.
Besides this, it's still time consuming to dump/restore a complete dbs with many databases, each one having many users, because each db needs to be dumped separately with the --dumpDbUsersAndRoles option in order to have users included (see TOOLS-760) or did I miss something?

Comment by Spencer Brody (Inactive) [ 16/Jun/15 ]

By the way I went ahead and filed TOOLS-770 to make mongorestore warn if it is restoring old-style user documents that will be ignored by a current version of mongodb.

Comment by Spencer Brody (Inactive) [ 16/Jun/15 ]

kay.agahd@idealo.de,
Thank you for your input. After some consideration and internal discussion, we have decided to re-open this ticket and grant all the privileges of the "restore" role to the "root" role.

When the "restore" role was first being designed it included some extra privileges that would make it easy for a user to accidentally corrupt their user and role definitions. Since then, however, we have changed how mongorestore handles restoring user and role definitions and removed those dangerous privileges from the "restore" role. It is always possible for a user with "root" to grant themselves the privilege to directly modify users and roles and thus corrupt the user and role definitions, but we wanted to avoid making it easy for someone to do so by accident. Now that those privileges are not included in the "restore" role, we feel it is safe to grant the "restore" role's privileges to "root".

As for your comments on the behavior of mongorestore - if you have any suggestions to changes of behavior to mongorestore or documentation changes we could make to make the existing behavior clearer we'd love to hear them! For changes to mongorestore behavior please file a ticket in the TOOLS project, and for changes to documentation please file one in the DOCS project.

Cheers,
-Spencer

Comment by Kay Agahd [ 28/May/15 ]

I just discovered that we need the mongodump option --dumpDbUsersAndRoles else users and roles won't be saved! mongodb documentation states (wrongly?) that the role backup is needed to do this. However, the dump was working ok with an user that had only root and restore role assigned.

For restoring the dump we needed the mongorestore option --restoreDbUsersAndRoles else users and roles won't be restored. For doing this you'll need the role restore, even as root.

The above mentioned log from mongorestore, saying that users have been restored, is simply misleading, since users are not stored in system.users anymore. The database we were dumping from was v2.6.4, thus users are stored already in the admin database, not in system.users. The system.users collections on this v2.6.4 database seems to be an survival from an earlier mongodb version, which caused some misleading information that I've posted above.

Perhaps some users may benefit from my experiences.
However, root should never need to add more roles to gain more privileges since root should have them all already!

Comment by Kay Agahd [ 28/May/15 ]

"Won't fix, workes as designed?" Root should be always root! Why do we need to add still more priviliges to root? Root should have them all already! Do we need to add still more roles than just restore to the root user to have all privileges or is the restore role the one and only that was missing?

Spencer, thanks for your explanation but I think simply not allowing to modify system.users is not a (good) solution. Instead, mongorestore should be smart enough to restore the old user format into the new format. With your "solution", even with the extra role restore enabled, users won't be restored in the right place.
As you can see in the following log snippet, restore says that users got restored but show users doesn't show any of them:

2015-05-27T18:19:00.838+0200	restoring offerStore_offermanager_dev2.system.users from file /data/dump_b30/offerStore_offermanager_dev2/system.users.bson
2015-05-27T18:19:00.838+0200	restoring offerStore_offermanager_dev2.offer from file /data/dump_b30/offerStore_offermanager_dev2/offer.bson
2015-05-27T18:19:00.845+0200	restoring indexes for collection offerStore_offermanager_dev2.system.users from metadata
2015-05-27T18:19:00.846+0200	finished restoring offerStore_offermanager_dev2.system.users

Mongo-Shell shows no users:

MongoDB shell version: 3.0.2
connecting to: s516:27017/admin
mongos> use offerStore_offermanager_dev2
switched to db offerStore_offermanager_dev2
mongos> show users
mongos> db.version()
3.0.2
mongos> 

Comment by Spencer Brody (Inactive) [ 21/Apr/14 ]

Hi Dharshan,
Sorry for the confusion, I agree that the documentation is misleading at the moment - I'll make sure that gets fixed soon.

The answer to your question requires some backstory. In versions prior to 2.6 all user management was done by directly manipulating the system.users collections. In 2.6 we changed things to discourage users from modifying system.users directly and instead recommend the use of the user management commands. The advantage using the commands is that they can do additional safety checks to make sure the user modification is valid and makes sense. For example, they can prevent you from creating a user with a non-existent role. To make sure that users would use the commands and not modify system.users directly we restricted it so that most of the built-in roles, including the "root" role, do not allow direct modification of admin.system.users (or admin.system.roles or admin.system.version). The problem is that mongorestore works by directly inserting BSON documents taken from the dump file into the target system, it does use the new user management commands. As such, for the "restore" role to be usable by mongorestore, it had to have an exception and be given the right to insert directly into admin.system.users, admin.system.roles, and admin.system.version. It is the only built-in role that has those privileges.

And to answer your first question: yes, you can have both "root" and "restore".

Hopefully that clears things up, please let me know if any part of my explanation was unclear or if you have any further questions about this.

Comment by Dharshan Rangegowda [ 21/Apr/14 ]

Hi Spencer,

Can I give the user both "root" and "restore" roles? The documentation led me to believe that "root" is the superset of all the privileges - which is why I was surprised that the root role does not have "restore" privileges on the admin db. If the "root" user can edit the collections in the admin db why not allow him to restore as well?

Comment by Spencer Brody (Inactive) [ 21/Apr/14 ]

Hi Dharshan, I have reproduced your problem and updated the ticket description with my findings. For now, we recommended that you use the "restore" role in the admin database when using mongorestore, rather than the "root" role.

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