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

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

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.6.10, 3.0.4
    • Component/s: Security
    • Labels:
      None
    • Fully Compatible
    • ALL
    • 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.
    • Security 6 07/17/15, Security 9 (09/18/15)

      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.

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

              Created:
              Updated:
              Resolved: