[SERVER-37015] Annotate Audit Records for Aborted Transactions Created: 06/Sep/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | 4.0.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Danny Hatcher (Inactive) | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
According to the docs, auditing will capture all operations within a transaction even if the transaction was eventually aborted. This can cause users to think that changes were made even though they never actually succeeded. Would it be possible to either not audit those failed transaction operations or to add a field to the audit log that can be used to indicate whether the transaction they were within succeeded/failed? |
| Comments |
| Comment by Spencer Jackson [ 14/Sep/18 ] |
|
Ops should be reported immediately, before the transaction commits or aborts. This is especially important for finds, for example. As such, we cannot flag events in the log with whether they were committed or not. The most important part is that the attempted action is recorded even if the action itself didn't complete. This means that auditing is not just a persisted version of the oplog. As such, even if we record an audit event to denote that we're about to commit a transaction, the server could then crash before the data is actually be committed. It should be possible to audit that commitTransaction commands were run, and the absence of a commitTransaction would suggest that the client didn't ask for the transaction to be committed. However, the presence of commitTransaction doesn't guarantee the transaction actually committed, |
| Comment by Danny Hatcher (Inactive) [ 06/Sep/18 ] |
|
It was brought up to me that we may want to audit transaction ops regardless of if the transactions commits or aborts for security reasons. Thus, the ideal solution would most likely be an indication in the audit log that the op ultimately committed or aborted. |