[SERVER-32640] killCursors auditing messages are duplicated or incomplete Created: 10/Jan/18 Updated: 30/Oct/23 Resolved: 05/Mar/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Sergey Galtsev (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Minor Change | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Security 2021-02-22, Security 2021-03-08 | ||||||||
| Participants: | |||||||||
| Description |
|
Run a mongod with auditing on: Then start up a shell and insert some data:
Then, run a find() command and then kill the cursor associated with it:
You will see three audit messages:
Now try it with aggregate():
You will again see three messages. However, the ns field of the second message is empty!
Now do the same for listCollections.
Again you will see three audit messages, and the second has an empty ns field.
Running killCursors on a find while using the shell with --readMode=legacy will produce only one audit message:
On an aggregate (with readMode legacy) it will produce one audit message, but with a missing namespace:
|
| Comments |
| Comment by Githook User [ 05/Mar/21 ] |
|
Author: {'name': 'Sergey Galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}Message: |
| Comment by Githook User [ 05/Mar/21 ] |
|
Author: {'name': 'Sergey Galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}Message: |
| Comment by Sergey Galtsev (Inactive) [ 19/Feb/21 ] |
|
I reproduced scenario on 3.6. I reproduced duplicating events on master, but not an empty ns, so it seems that this specific issue is gone. Will be working on deduplication only |
| Comment by Ian Boros [ 18/Feb/21 ] |
|
sergey.galtsev My guess is that I was running 3.6 or a development version of 4.0.
A lot of the cursor management code has been refactored in the last three years so I would not be surprised if some of these issues have just gone away. |
| Comment by Sergey Galtsev (Inactive) [ 18/Feb/21 ] |
|
ian.boros I am trying to reproduce your steps and not all results match your write-up. Do you happen to recall what version were you using when you ran the commands? I would like to make sure I can fully reproduce the issue before fixing it, so that I can know I am not missing anything |
| Comment by Davi Ottenheimer [ 20/Feb/18 ] |
|
does not appear critical as workarounds do exist and audit could still be done on cursor actions, even though less convenient. appears to be more of a quality bug that needs ns to be filled in to ensure audit functioning consistently across operations. |
| Comment by Ian Whalen (Inactive) [ 19/Jan/18 ] |
|
Moving this to the Platforms team because the Query team doesn't know how to triage it. They are happy to help with implementation if it is important. |