Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-13647

root role does not contain sufficient privileges for a mongorestore of a system with security enabled

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 2.6.0, 3.0.4
    • Fix Version/s: 3.0.7, 3.1.8
    • Component/s: Security, Tools
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Completed:
    • Sprint:
      Security 7 08/10/15, Security 8 08/28/15

      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)

      1. core.13738
        57.68 MB
        Dharshan Rangegowda

        Issue Links

          Activity

          Hide
          spencer Spencer T Brody added a comment -

          kay.agahd,
          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

          Show
          spencer Spencer T Brody added a comment - kay.agahd , 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
          Hide
          spencer Spencer T Brody added a comment -

          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.

          Show
          spencer Spencer T Brody added a comment - 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.
          Hide
          kaga kay.agahd added a comment -

          Spencer T Brody 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?

          Show
          kaga kay.agahd added a comment - Spencer T Brody 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?
          Hide
          xgen-internal-githook Githook User added a comment -

          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

          Show
          xgen-internal-githook Githook User added a comment - 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
          Hide
          xgen-internal-githook Githook User added a comment -

          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

          Show
          xgen-internal-githook Githook User added a comment - 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

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                  Agile