[SERVER-31641] clusterTime should not gossip between Mongo shell objects Created: 19/Oct/17 Updated: 30/Oct/23 Resolved: 13/Nov/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Jackson | Assignee: | Mira Carey |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Platforms 2017-11-13 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
If a Mongo object in a shell process performs an operation as the __system user, it will receive a clusterTime with an empty signature. Currently, every Mongo object in the shell will gossip this signature to every server in the cluster. However, if one of these objects is not authenticated as __system, the server will reject the signature, and its commands will begin failing. This can be prevented by making each Mongo object maintain its own independent store of clusterTime, which are not process global. |
| Comments |
| Comment by Githook User [ 13/Nov/17 ] |
|
Author: {'name': 'Jason Carey', 'username': 'hanumantmk', 'email': 'jcarey@argv.me'}Message: Mongo client objects in the shell should not gossip cluster time. |
| Comment by Spencer Jackson [ 27/Oct/17 ] |
|
I blacklisted sharding/kill_sessions.js, until this ticket is resolved. |
| Comment by Githook User [ 27/Oct/17 ] |
|
Author: {'email': 'spencer.jackson@mongodb.com', 'name': 'Spencer Jackson', 'username': 'spencerjackson'}Message: |
| Comment by Spencer Jackson [ 25/Oct/17 ] |
|
greg.mckeon, Yes I obtained confirmation that this change is acceptable from misha.tyulenev and schwerin. |
| Comment by Gregory McKeon (Inactive) [ 25/Oct/17 ] |
|
spencer.jackson regarding the above, have we confirmed this is the right path forward? |