[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:

 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.

Generated at Thu Feb 08 05:04:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.