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

root role should be able to run validate on system collections

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.7, 3.1.7
    • Component/s: Security
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Backport Completed:
    • Sprint:
      Security 7 08/10/15, Security 8 08/28/15

      Description

      The root role is only defined with limited access to the system.* collections. Users, however, expect the role named "root" to be unlimited, much like the Unix root superuser. This means that it is surprising and counter-intuitive when, after authenticating as root, the user is denied permission to run certain operations on system collections (eg. validate). The documentation also presents the root role as being an "unlimited superuser role".

      I understand that most of the other built-in roles (which root is built out of) should not be modified to include unlimited access to the system collections, as this would not be appropriate. However, it would be good if the root role could be modified to include specific privileges for all possible operations on the system collections of all databases. Since the "root" role is named as an all-encompassing unlimited role, this could be argued as being appropriate.

      It is true that users could define a role that extends the root role to include these additional privileges. However, as above, the naming implies that this is already the case, and users often expect this to be the case (it is difficult to explain the necessity to define a "super-root" role that includes all of root, and then some).

      Currently, most of the system collections get

      "actions" : [
              "collStats",
              "dbHash",
              "dbStats",
              "find",
              "killCursors",
              "planCacheRead"
      ]
      

      (though this does vary a little for some collections, and on some databases)

      It would be great if privilege documents could be included in the root role (only) which grant all possible actions, for each of the possible system collections, ie:

      {
              "resource" : {
                      "db" : "",
                      "collection" : "system.indexes"
              },
              "actions" : [
                      "changeCustomData",
                      "changePassword",
                      "collMod",
                      "collStats",
                      "compact",
                      "convertToCapped",
                      "createCollection",
                      "createIndex",
                      "createRole",
                      "createUser",
                      "dbHash",
                      "dbStats",
                      "dropCollection",
                      "dropDatabase",
                      "dropIndex",
                      "dropRole",
                      "dropUser",
                      "emptycapped",
                      "enableProfiler",
                      "enableSharding",
                      "find",
                      "getShardVersion",
                      "grantRole",
                      "indexStats",
                      "insert",
                      "killCursors",
                      "moveChunk",
                      "planCacheIndexFilter",
                      "planCacheRead",
                      "planCacheWrite",
                      "reIndex",
                      "remove",
                      "renameCollectionSameDB",
                      "repairDatabase",
                      "revokeRole",
                      "splitChunk",
                      "splitVector",
                      "storageDetails",
                      "update",
                      "validate",
                      "viewRole",
                      "viewUser"
              ]
      },
      

      (and the same for the rest of the system collections).

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: