[SERVER-32374] killCursors potential race/ABA problem Created: 15/Dec/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Operating System: | ALL |
| Participants: |
| Description |
|
The killCursors command works by: It seems like there could be an ABA problem here. Say user X tries to destroy the cursor C. The server receives the command and the auth check passes (step 2). Then, between steps 3 and 4, the cursor is exhausted and cleaned up. User Y then creates a cursor on the same collection and happens to get the same cursor id as C. Step 4 of user X's killCursors command now runs, and at step 5, kills the cursor with id C (which is user Y's cursor!). It seems like the best way to go is to just perform the authentication check as part of the run() portion of the command to avoid the double-locking we currently do. The getMore command does something similar. Note that the changes from |