[SERVER-43994] Verify configOpTime metadata in message with invalid cluster time signature is ignored with auth on Created: 14/Oct/19 Updated: 08/Jan/24 Resolved: 16/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2019-10-21 |
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
When auth is enabled, the cluster times gossiped throughout a sharded cluster are signed and validated using keys from a collection on the config server. If a node in one cluster with auth enabled receives a message with a cluster time signed using the keys from a different cluster (or not signed at all), that request should be rejected by the node and the node should not advance its understanding of the latest config server opTime. The purpose of this ticket is to verify this with a test. |
| Comments |
| Comment by Jack Mulrow [ 16/Oct/19 ] |
|
After further investigation, resolving this ticket without a commit because the scenario in the description is prevented by our auth system, which is already tested. In particular, with auth enabled, requests must be authorized to run on a node, which is validated before a request's cluster time or configOpTime is processed, so as long as a rogue node gossiping an incorrect configOpTime isn't authorized, which it shouldn't be if it belongs to a different sharded cluster, the recipient node's configOpTime won't advance regardless of its cluster time signature. |