[SERVER-80475] Stop audit_synchronize_job from running during FCV transition on mongos Created: 28/Aug/23 Updated: 29/Oct/23 Resolved: 05/Sep/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gabriel Marks | Assignee: | Gabriel Marks |
| 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: | Security 2023-09-04, Security 2023-09-18 | ||||
| Participants: | |||||
| Linked BF Score: | 47 | ||||
| Description |
|
Previously, I thought this was only a problem on mongod. However, it seems like there's a race condition on mongos where audit_synchronize_job is executing and fetching the old audit config from the cluster, and right after the cluster parameter refresher is executing and fetches the new audit config, but the refresher finishes first and the old audit config is then set and returned by getAuditConfig. We should block audit_synchronize_job from running on transitional cluster versions to prevent this. |
| Comments |
| Comment by Githook User [ 05/Sep/23 ] |
|
Author: {'name': 'Gabriel Marks', 'email': 'gabriel.marks@mongodb.com', 'username': 'marksg07'}Message: |