[SERVER-55870] Add diagnostic information to killOp and killSession* logging Created: 07/Apr/21 Updated: 29/Oct/23 Resolved: 23/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Security |
| Affects Version/s: | None |
| Fix Version/s: | 5.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Sergey Galtsev (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.4, v4.2
|
||||||||||||
| Sprint: | Security 2021-05-17, Security 2021-06-14, Security 2021-06-28 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
Always log successful killOp and killSession* commands in the system log. We should include any relevant diagnostics, such as the user doing the killing and the user being killed, and the client metadata. |
| Comments |
| Comment by Githook User [ 23/Jun/21 ] |
|
Author: {'name': 'Sergey Galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}Message: |
| Comment by Sergey Galtsev (Inactive) [ 09/Jun/21 ] |
| Comment by Sergey Galtsev (Inactive) [ 08/Jun/21 ] |
|
I brought this up on today's team meeting, and we decided that the way to resolve this ticket would be to log parameters, as tracking session IDs would be too large code change which would also make back-porting risky. |
| Comment by Judah Schvimer [ 08/Jun/21 ] |
|
I think we should aim to log the actual sessions that were killed. If that is significantly harder, logging the command that was executed seems like a reasonable alternative. |
| Comment by Sergey Galtsev (Inactive) [ 07/Jun/21 ] |
|
judah.schvimer when command such as killAllSessionsByPattern runs, it is undefined what sessions would actually be killed. For the purpose of this ticket is it important to log what exactly sessions were killed as a result of this command's execution, or should we only log that command was executed and was successful? |
| Comment by Judah Schvimer [ 01/Jun/21 ] |
|
My opinion is that the perf and disk space impact of 1 default log line on every killOp and killSessions command will be worthwhile. |
| Comment by Sergey Galtsev (Inactive) [ 01/Jun/21 ] |
|
judah.schvimer milkie given that this command has potential impact on a) performance, and b) disk space, do we want to enable it everywhere by default, or should it be something that user turns on knowingly via flag or increased debug level? |
| Comment by Eric Milkie [ 19/Apr/21 ] |
|
Auditing is an Enterprise-only feature, so by using auditing you would be restricting the diagnostic information to Enterprise as well. |
| Comment by Sara Golemon [ 19/Apr/21 ] |
|
Curious if using the audit log for this was discussed. I believe this information is already captured there and auditing feels like a more correct place to put something non-exceptional like this. |
| Comment by Eric Milkie [ 12/Apr/21 ] |
|
Since killOp commands are very fast and won't cost users anything, there is a significant resource exhaustion issue if we choose to log every command received in the global system log and a user hammers on the command (intentionally or not). Therefore it is important that this be "successful commands only". |
| Comment by Judah Schvimer [ 12/Apr/21 ] |
|
This is intended to log all successful killOp/sessions commands. Thank you for the clarifying question! |
| Comment by Eric Milkie [ 09/Apr/21 ] |
|
Is the behavior to log a message in the system log for every killOp command ever received, successful or not? |