The direct answer
Review the actual worker’s dumpability state and crash-collection route rather than treating a zero core-size limit as universal no-copy evidence. Bind any suppression claim to that process’s supported lifetime, and keep existing artifacts, application diagnostics and other memory access outside the claim.
A clean application log is not a complete crash-copy policy
A trusted native preprocessing worker handles one admitted maintenance note. Its normal logs contain only minimized identifiers. If the process fails, an operator expects no copy of the note because the launch plan says the core-size limit is zero.
The core(5) manual describes a core dump as a process-memory image produced by certain terminating signals. It explicitly says RLIMIT_CORE is not enforced when dumps are piped to a program. The collector receives the dump on standard input.
The payload-minimization guide and structured-audit guide still apply. A native crash-copy route does not become covered merely because the application’s logging formatter excludes note text.
This worksheet selects one fixed Linux native worker W-A and admitted input I-A. All eight cards are PROPOSED_UNRUN. No process, crash, signal, memory image, collector or host configuration was inspected or exercised.
Name the process-state condition precisely
PR_SET_DUMPABLE controls the calling process’s core-dump attribute. The documented disabled value is 0L; success returns zero, while error returns minus one with errno. A helper’s success is not evidence that W-A is the process covered.
For the proposed plan, require supported state setup associated with W-A before I-A enters it, plus coverage of the complete sensitive-processing lifetime. Record the admitted native program revision, process association and setup disposition without publishing actual process identifiers or protected paths.
The underlying kernel, libc, ABI, actual current state and complete launch association remain unknown here. These are prerequisites, not proof supplied by an intended flag or a previous worker’s receipt. This article gives no syscall snippet, getter, launch adapter or process-inspection procedure. Missing evidence holds the plan instead of substituting a different helper.
Separate documented resets from a stricter no-transition profile
The same manual lists resets after effective or filesystem user/group ID changes, set-ID execution that changes effective IDs, and file-capability execution that gains permitted capabilities beyond the prior set. The reset uses the current suid_dumpable setting; its value is not established here.
That is not a claim that every ordinary exec resets the attribute. Our application profile is deliberately stricter: no identity-changing or re-exec transition after the supported setting while I-A is handled. This avoids extending a limited setup receipt across an unexplained transition. It does not redefine the manual’s reset list.
If the real worker needs such a transition, this profile cannot approve it. Require separately supported lifecycle evidence rather than guessing that the state persisted or automatically became disabled. The worksheet supplies no credential-drop, capability arithmetic, exec sequence or restoration recipe.
Review the collector as a separate data destination
core(5) places a piped collector in the initial namespaces rather than the crashing process’s namespaces. Its complete processing and storage policy therefore needs separate evidence; an application’s local output inventory is insufficient.
Use invented disposition sheet D-A for W-A/I-A. It names the supported process-state coverage, unchanged selected processing lifetime, effective file-or-pipe core route, collector owner and handling status, current input rights, and unresolved prior artifacts. A route being known does not mean it is approved to retain data. Unknown collector behavior remains unknown.
The selected positive requires the complete nondumpable-state association, not permission for a collector to receive I-A. If another authorized design deliberately retains crash artifacts, it needs its own access, destination and retention policy. Do not paste memory contents into ordinary incident tickets to demonstrate what a collector might capture. A route review creates no evidence that a particular dump exists or was deleted.
Walk eight inert crash-disposition cards
| Card | Proposed condition | Disposition |
|---|---|---|
| 1. Ordinary admitted note | Complete supported same-worker state, unchanged lifetime, known route and all prerequisites established. | Conditionally admit the narrow core-disposition plan for ordinary processing review. |
| 2. Size limit alone | Zero core-size limit offered while a piped route is possible or unknown. | No universal no-copy claim; reconcile the documented exception. |
| 3. Wrong process receipt | Unrelated launcher/helper reports setup success. | Hold W-A association; do not transfer the receipt. |
| 4. Transition after setup | Credential change or re-exec occurs while I-A is handled. | Outside this stricter profile; preserve the exact reset distinction and unknown coverage. |
| 5. Deliberate file artifact | Another policy permits a core file. | Separate sensitive-artifact authorization and retention; it is not sanitized log output. |
| 6. Collector unresolved | Collector input handling, storage or forwarding scope lacks evidence. | Hold the complete disposition, even if application logging is reviewed. |
| 7. Logs are minimized | Only the audit formatter has been reviewed. | Keep native crash-copy coverage unresolved; the formatter is a different boundary. |
| 8. No file observed | No local artifact appears, or older copies may already exist. | No current-state, recall or erasure inference; do not manufacture a crash test. |
Keep the useful claim narrower than memory confidentiality
The ordinary positive is one trusted worker processing a small currently authorized note with an independently supported core-suppression plan. Actual same-worker state, route/collector handling, unchanged processing lifetime and current rights remain unimplemented prerequisites. Without them, the plan stays held; no observed dump suppression is claimed.
Both references identify Linux man-pages 6.19, dated 7 May and 8 February 2026 respectively. Documentation applicability is separate from installed-host evidence. This is not a guarantee against privileged observers, application diagnostics, swap, hibernation or other existing copies. A later state change cannot recall an earlier artifact.
No crash, signal, prctl/getter, procfs, sysctl, limit, collector, memory or runtime experiment occurred. No API or model call was made. Boundary remains prelaunch with planned request-path checks, not a shipped native dumpability controller or crash-artifact prevention engine.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.