[SERVER-32936] Ban collMod on admin.system.version Created: 26/Jan/18 Updated: 27/Feb/18 Resolved: 26/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | William Schultz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Sprint: | Repl 2018-02-26, Repl 2018-03-12 | ||||
| Participants: | |||||
| Description |
|
Previous summary: "collMod oplog entries on `admin.system.version` fail initial sync" |
| Comments |
| Comment by William Schultz (Inactive) [ 26/Feb/18 ] |
|
Filed SERVER-33490 to implement these fixes. |
| Comment by William Schultz (Inactive) [ 26/Feb/18 ] |
|
This logic in applyCommand_inlock bans any commands that operate on the admin.system.version namespace other than "dropDatabase", "applyOps", or "dbCheck" during initial sync. This logic in applyOperation_inlock disallows any CRUD operations that try to modify the Feature Compatibility Version document in the admin.system.version collection. The simplest fix for the fuzzer would probably be to blacklist the following:
|
| Comment by Judah Schvimer [ 09/Feb/18 ] |
|
Most of the failing is done here: https://github.com/mongodb/mongo/blob/7a97a67879f171eb8bd6748c4a7e1bcd8f328490/src/mongo/db/repl/oplog.cpp#L1526-L1541 and here: https://github.com/mongodb/mongo/blob/7a97a67879f171eb8bd6748c4a7e1bcd8f328490/src/mongo/db/repl/oplog.cpp#L1080-L1092 |
| Comment by Spencer Brody (Inactive) [ 08/Feb/18 ] |
|
We should just ban collMod on admin.system.version in the access control system. |