-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 2.6.10, 3.0.4
-
Component/s: Security
-
None
-
Fully Compatible
-
ALL
-
-
Security 6 07/17/15, Security 9 (09/18/15)
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.
- is duplicated by
-
SERVER-25994 Allow applyOps to validate authorization permissions at the operation level
- Closed