[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: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| 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" , name: "id", ns: "admin.system.version" } |
| Comments |
| Comment by Githook User [ 31/Aug/15 ] | ||||||||||||
|
Author: {u'name': u'Merry Mou', u'email': u'merry.mou@mongodb.com'}Message: | ||||||||||||
| Comment by Githook User [ 21/Aug/15 ] | ||||||||||||
|
Author: {u'name': u'Merry Mou', u'email': u'merry.mou@mongodb.com'}Message: | ||||||||||||
| 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. | ||||||||||||
| 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, 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, | ||||||||||||
| 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. | ||||||||||||
| 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.
Mongo-Shell shows no users:
| ||||||||||||
| Comment by Spencer Brody (Inactive) [ 21/Apr/14 ] | ||||||||||||
|
Hi Dharshan, 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. |