[SERVER-19191] "restore" role does not have applyOps permissions on servers using a keyFile Created: 29/Jun/15 Updated: 05/Apr/17 Resolved: 17/Oct/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 2.6.10, 3.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kyle Erf | Assignee: | Spencer Jackson |
| Resolution: | Duplicate | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Steps To Reproduce: |
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) | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Issue Status as of Jul 14, 2015 ISSUE SUMMARY USER IMPACT WORKAROUNDS 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 descriptionThis 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
Note that when using a user with the __system role, applyOps will work in both cases. |
| Comments |
| Comment by Spencer Jackson [ 17/Oct/16 ] | ||||||||||||
|
I have tested this again on 3.3, after the work done in
Running ``db.createCollection("foo")``` from the 'ccc' database, and running the applyOps command results in:
I will now close this ticket. | ||||||||||||
| Comment by Andreas Nilsson [ 15/Jul/15 ] | ||||||||||||
|
We have reproduced the problem and --oplogReplay and auth does not play well together. The reason is that --oplogReplay uses applyOps which requires universal privileges on the system. We're going to try to rewrite the applyOps permission check to be more granular to the actual operations that are to be performed. Before applying the requested operations we will refactor the authorization check to loop through the list of operations and perform individual authorization checks on each one of them. |