[SERVER-38071] Abandon snapshot after read in AuthzManagerExternalStateMongod::findOne Created: 09/Nov/18 Updated: 29/Oct/23 Resolved: 30/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.8 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Xiangyu Yao (Inactive) | Assignee: | Jonathan Reams |
| 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 2018-12-03, Security 2018-12-17, Security 2019-01-14, Security 2019-01-28, Security 2019-02-11 | ||||
| Participants: | |||||
| Linked BF Score: | 52 | ||||
| Description |
|
AuthzManagerExternalStateMongod::findOne uses AutoGetCollectionForReadCommand to get the lock and does the read. Normally, the destructor of AutoGetCollectionForReadCommand would abandon the WiredTiger snapshot due to the destructor of Global lock. However, we may enter this findOne function with AuthzLock (a Database S lock and thus a Global IS lock). So therefore the destructor would not abandon the snapshot. In the linked BF, the first read opened a transaction and the second read just continued that transaction. If the snapshot is invalid for the second read, there is no way to set the readSource since the transaction is already active. The fix would be to abandon the snapshot after the first read or always abandon snapshots before any findOne() so each read would be independently using its own snapshot/transaction. If two reads have to be on the same transaction/snapshot, we definitely need a better way, especially if they are on two different collections. |
| Comments |
| Comment by Githook User [ 13/Mar/19 ] |
|
Author: {'name': 'Jonathan Reams', 'username': 'jbreams', 'email': 'jbreams@mongodb.com'}Message: Revert " This reverts commit eace76975fd1c521993e82fdc0c2c7833f84ed48. |
| Comment by Githook User [ 30/Jan/19 ] |
|
Author: {'username': 'jbreams', 'email': 'jbreams@mongodb.com', 'name': 'Jonathan Reams'}Message: |