[SERVER-32672] Standalone replica set shards reject requests with gossiped clusterTime from non __system users Created: 11/Jan/18  Updated: 30/Oct/23  Resolved: 30/Apr/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Misha Tyulenev
Resolution: Fixed Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-32052 Update ShardingTest to default to sta... Closed
is depended on by SERVER-31937 de-blacklist sharding kill_sessions.js Closed
Related
related to SERVER-43486 Complete TODO listed in SERVER-32672 Closed
is related to SERVER-60466 Support drivers gossiping signed $clu... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-05-07
Participants:

 Description   

Replica set nodes started with --shardsvr create their KeyManager and LogicalTimeValidator when they are added to a cluster and initialize their sharding state, unlike config servers, standalone replica set nodes, and mongos, which create them up at startup. So before being added to a cluster, any request from a user other than __system that gossips a clusterTime will be rejected with ErrorCode::CannotVerifyAndSignLogicalTime, because there is no validator available. This was masked in v3.6, because we only validated or signed logical times if FCV was fully upgraded to 3.6, and shard servers default to FCV 3.4 after a clean startup.

Once we remove these FCV checks in SERVER-32463, we'll have a problem in our test infrastructure, because when calling ShardingTest with replica set shards and a keyfile, the shell briefly authenticates as __system and receives a dummy signed clusterTime from the newly set up shard (because times aren't signed for internal clients) and then calls awaitSecondaryNodes on the shard without authenticating as __system and will attempt to gossip a clusterTime and will be unable to receive an ismaster response from each secondary, causing the test to timeout.

This may be desired behavior, but we still need to untangle this from FCV, since currently the implementation details of upgrade/downgrade determine how clusterTime is handled and those checks will be removed before the next release.



 Comments   
Comment by Githook User [ 01/May/18 ]

Author:

{'email': 'misha@mongodb.com', 'name': 'Misha Tyulenev', 'username': 'mikety'}

Message: SERVER-32672 reset session and connection clusterTime
Branch: master
https://github.com/mongodb/mongo/commit/b786f13ab28e275bffded1302b21bfd88977150d

Comment by Githook User [ 30/Apr/18 ]

Author:

{'email': 'misha@mongodb.com', 'username': 'mikety', 'name': 'Misha Tyulenev'}

Message: SERVER-32672 reset session and connection clusterTime
Branch: master
https://github.com/mongodb/mongo/commit/b786f13ab28e275bffded1302b21bfd88977150d

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