ghalvera/
acceptedretrieval17 aug 2026

R-002-01 / RETROSPECTIVE MOTIVATING SPECIMEN

The tool said there was no evidence.
The evidence was there.

ausearch -k <key> returned no matches and exited 0. The same configured log, read explicitly, returned 186 parsed matches. A raw search found 192 keyed lines.

DECLARED QUERY0matches / exit 0
≠
EXPLICIT LOG INPUT186parsed matches
≠
RAW RECORD192keyed lines

RETRIEVAL ≠ ABSENCE

substrate
Fedora 44 · kernel 6.19.10 · aarch64
audit
4.1.4
state
accepted / retrospective

01 / Result

invocationrecords returned
ausearch -k ghalvera_exec0 — “no matches”, exit 0
ausearch -m SYSCALL0
ausearch --start today / --start recent / no bound0
aureport --summarytime range 01/01/1970 – 01/01/1970
ausearch --input-logs -k ghalvera_exec186
ausearch -if <log> -m SYSCALL771
aureport --input-logs --summary08/15/2026 – 08/17/2026
grep on the same file, same moment192

02 / Mechanism

Reading the configured audit log is opt-in. With neither --input-logs nor -if, the tool consumes stdin. With no redirect it reaches EOF immediately and reports an absence of matches rather than an absence of input.

--input-logs uses the configured audit log as input. The utility can otherwise consume raw audit data from stdin.

aureport behaves identically. Its 1970 time range is the tell: minimum and maximum timestamps never move off initialisation when zero records parse.

03 / Inference boundary

VALID OBSERVATION“ausearch returned no matches.”does not establishREQUESTED CONCLUSION“No matching audit evidence exists.”

No error. No warning. Exit status 0. Meanwhile auditctl -s reported enabled 1 and lost 0. The subsystem was genuinely healthy, making the unsupported conclusion unusually plausible.

04 / Isolation

Three hypotheses were eliminated first, each costing a controlled run. They remain in the record because the next investigator should not repeat them.

cell-a task,neveraudit=1ausearchraw log
Apresentabsent0present
Bremovedabsent0present
Cpresentadded0present
ausearch -m SYSCALL        0   → not key-specific
aureport time range     1970   → not ausearch-specific
with --input-logs        771   → the log was always readable

05 / Not determined

  • Whether this is a change in audit 4.x or long-standing upstream behaviour. Not established.
  • Whether Fedora 44 configuration affects it, or it is purely upstream.
  • Whether it reproduces on x86-64, bare metal, or outside Lima/vz.
  • How common the bare invocation is in published runbooks. That has not been measured.

06 / Corrections

This finding was published wrong twice before it was published right. Both superseded interpretations remain in repository history.

  1. 1
    “Linux Audit recorded nothing.”Wrong. It recorded everything. The error was inferring absence from a retrieval tool's silence.
  2. 2
    “The cause is unknown.”Honest at the time, now superseded after the decisive control was run.

07 / Consequence

Any procedure reading audit evidence must pass --input-logs or -if explicitly, and verify a non-empty result against the raw log before treating an empty one as evidence of absence.

Both range scenarios now count raw-log hits alongside the tool's answer, making this class of discrepancy part of the artifact rather than a later discovery.

studyR-002-01
treatmentretrospective
claim stateaccepted
canonical/studies/audit-retrieval.html