Module audit

Expand description

The audit log: who did what, where, through which door, and how it went.

SQLite at <state>/audit.db, its own file (0600 in a 0700 directory) so it keeps its own retention and never shares migrations with the identity store. The daemon and the local CLI both append to it.
Append only. There is no update or delete API, and triggers refuse UPDATE and any DELETE outside retention pruning.
Tamper evident. Each row carries the SHA-256 of the row before it (prev_hash) and its own (hash, over its fields and prev_hash), so editing, removing or reordering a row breaks the chain from there on (AuditLog::verify). Pruning keeps the last pruned row’s hash, so the chain still starts somewhere known. Anyone who can write the file can rebuild a whole chain; copy Verified::head elsewhere to pin it.
Never values. Rows hold names and identifiers the caller chose to put in NewEntry::details (the daemon keeps a whitelist of argument keys); never tool arguments wholesale, secret values or error messages.

Structs§

Actor: Who acted.
AuditLog
Entry: A stored row.
NewEntry: A row to append. details must hold only names and identifiers: the log never redacts, it only stores what it is given.
Origin: Where a request came in and how to correlate it.
Query: A query. Globs are shell-style (*, ?, [a-z], [!x]).
Verified: What AuditLog::verify found.