Core dumps help engineers diagnose crashes. They can also contain encryption keys, session material, submitted form data, and fragments of memory from privileged work. On Linux, the fs.suid_dumpable setting decides how the kernel treats dumps for processes that normally would not produce one. Mode 2 is the safe mode only when a second setting remains correct.

The three modes

The kernel documentation describes fs.suid_dumpable=0 as disabling dumps for processes that would otherwise be protected. Mode 1 permits a dump, with access restrictions that make the resulting file readable only by root. Mode 2 allows the dump only when kernel.core_pattern points to a pipe handler or a fully qualified path.

That dependency matters because a host can appear to have a controlled dump policy while the effective pattern sends output somewhere unexpected. The kernel may also warn in the system log when mode 2 is selected without a suitable pattern. An operator can inherit an old core_pattern from an image, a configuration-management default, or a temporary debugging session.

What can end up in a dump

A crash image is a memory snapshot, not a curated diagnostic bundle. Applications should not assume that a cleared request object, a temporary credential, or a password field has disappeared from memory when the HTTP response has been sent. Languages with automatic memory management add another limitation: the application cannot reliably choose when a copy disappears.

For a setuid process, a daemon handling secrets, or a service that receives authentication tokens, the loss of a dump is a data handling event. The risk is higher when dumps land on a shared volume or are forwarded to a collector that has broad read access.

Verify the effective pair

Start with the runtime values, not a copied configuration file:

sysctl fs.suid_dumpable
sysctl kernel.core_pattern
cat /proc/sys/kernel/core_uses_pid

Record whether the pattern begins with a pipe. If it is a file path, confirm that it is absolute and that the directory permissions prevent ordinary users from browsing generated files. If it is a pipe, identify the handler in the receiving process and test where the data is stored.

Then inspect the service manager's limits. A coredump manager can collect a dump even when a shell session would not. Check the collector's configuration, retention period, encryption, and access controls. A dump that is deleted after seven days is still exposed to every reader during those seven days.

Test with a disposable process

Use a non-production host and a harmless program. Set the expected sysctls, trigger a controlled crash, and observe the file or pipe result. Verify both the successful path and the negative path where the pattern is removed or made unsafe. Restore the test host afterwards.

Do not generate dumps from a production service merely to see whether a credential appears. That converts a configuration check into an incident. A disposable process can prove that the pipeline is active without placing real secrets on disk.

The final review should answer four questions. Which services can create dumps? Where does the kernel send them? Who can read the destination? How long are they retained? If the answer depends on a manual step, make the step observable in configuration and deployment checks. The goal is useful crash evidence with a shorter path from memory to deletion.

References