[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:

 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.

Generated at Thu Feb 08 04:44:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.