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

"restore" role does not have applyOps permissions on servers using a keyFile

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: 2.6.10, 3.0.4
    • Fix Version/s: None
    • Component/s: Security
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      mongod --fork --dbpath data --logpath data/mongod.log --keyFile test-keyfile
      mongo localhost/admin --quiet --eval 'db.createUser({user: "admin", pwd: "pass", roles: ["restore"]})'
       
      mongo -u admin -p pass --authenticationDatabase admin
      db.runCommand({ applyOps: [ { ts: Timestamp(142,455), h: 5831926941336282060, v: 2, op: "i", ns: "ccc.foo", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} }]})
      {
        "ok": 0,
        "errmsg": "not authorized on test to execute command { applyOps: [ { ts: Timestamp 142000|455, h: 5.831926941336282e+18, v: 2.0, op: \"i\", ns: \"ccc.foo\", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} } ] }",
        "code": 13
      }
      

      If you restart the server without a keyFile, the same user will be able to successfully run the applyOp.

      Show
      mongod --fork --dbpath data --logpath data/mongod.log --keyFile test-keyfile mongo localhost/admin --quiet --eval 'db.createUser({user: "admin", pwd: "pass", roles: ["restore"]})'   mongo -u admin -p pass --authenticationDatabase admin db.runCommand({ applyOps: [ { ts: Timestamp(142,455), h: 5831926941336282060, v: 2, op: "i", ns: "ccc.foo", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} }]}) { "ok": 0, "errmsg": "not authorized on test to execute command { applyOps: [ { ts: Timestamp 142000|455, h: 5.831926941336282e+18, v: 2.0, op: \"i\", ns: \"ccc.foo\", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} } ] }", "code": 13 } If you restart the server without a keyFile, the same user will be able to successfully run the applyOp.
    • Sprint:
      Security 6 07/17/15, Security 9 (09/18/15)

      Description

      Issue Status as of Jul 14, 2015

      ISSUE SUMMARY
      The restore role does not provide users access to the applyOps command, which mongorestore uses with the --oplogReplay option.

      USER IMPACT
      mongorestore --oplog will not apply oplog entries captured during the mongodump operation, and exit with an error when attempting to use mongorestore with the restore role and a MongoDB deployment that uses access control. For additional information, please review the documentation on the restore role

      WORKAROUNDS
      To restore data using the mongorestore --oplogReplay option, users may create a role that grants anyAction on anyResource. Do not assign this role to any other user. This role provides full unrestricted access to the system.

      Alternatively users can disable authentication while restoring data by starting mongod instances without the --auth option during the installation and then re-enabling --auth after completing the restoration.

      Original description

      This edge case breaks mongorestore --oplogReplay on 2.6 and 3.0 systems using auth and keyFile together.

      When using a shell as a user with the restore role, you should always be able to run an applyOps command, as these are essential to mongorestore jobs. Running applyOps as a restore user works on a mongod instance running without keyFile, however, if you restart the sever with a --keyFile file option, the same user will not be able to run the command successfully. The server returns

      Failed: restore error: error applying oplog: applyOps: not authorized on admin to execute command { applyOps: [ {...} ] }
      

      Note that when using a user with the __system role, applyOps will work in both cases.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              spencer.jackson Spencer Jackson
              Reporter:
              kyle.erf Kyle Erf
              Participants:
              Votes:
              1 Vote for this issue
              Watchers:
              15 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: