A service receives credentials into process memory, drops privileges, and continues running under an ordinary account. Another same-account process may still be able to inspect it through interfaces intended for debugging. Linux places an additional process attribute, commonly called dumpable, into several of these access decisions.
prctl(PR_SET_DUMPABLE, 0) marks the calling process non-dumpable. The effect is broader than suppressing a core file: Linux also incorporates dumpable state into ptrace access checks and changes ownership behavior for files under /proc/<pid>. These effects form related boundaries, but they are not a single universal ban on process observation.
Dumpable state is a process attribute, not a core-file switch
PR_SET_DUMPABLE accepts SUID_DUMP_DISABLE or SUID_DUMP_USER, represented by 0 and 1. A value of 0 makes the process non-dumpable; a value of 1 makes it dumpable under the ordinary rules.
Core generation still depends on other conditions. Resource limits, filesystem conditions, kernel configuration, signal disposition, and the system core-dump policy can all affect whether a dump is produced. Setting dumpable to 1 therefore does not promise that a core file will appear, and setting it to 0 has security consequences outside core generation.
The distinction matters in long-running services. Treating the flag only as crash-output configuration misses the access-control decisions that consume the same state.
Credential transitions can reset the attribute
Linux normally starts processes in dumpable state 1. Certain credential transitions reset the attribute to the value configured by /proc/sys/fs/suid_dumpable, whose conventional default is 0.
The documented reset cases include changes to effective user or group IDs, changes to filesystem user or group IDs, execution of set-user-ID or set-group-ID programs that changes effective credentials, and execution of a file-capability program when the permitted capability set grows.
This automatic reset protects privilege transitions from retaining an inspection posture that was suitable before the transition. It also means application code cannot assume a value set earlier remains unchanged across every credential operation.
A service that deliberately sets a final dumpable policy must place that operation relative to its credential changes with care. The policy is stateful, and later transitions can alter it.
Ptrace still performs a layered authorization decision
A non-dumpable process cannot be attached with ordinary PTRACE_ATTACH merely because the tracer has the same user ID. Dumpable state participates in Linux ptrace access checking, reducing an inspection path that same-account processes can otherwise possess.
This does not make PR_SET_DUMPABLE a complete ptrace policy. Capability checks, credential comparisons, user namespaces, and Linux Security Modules can also affect ptrace authorization. The Yama LSM can impose additional relationship or administrative restrictions through its own policy.
The useful boundary is therefore additive. Non-dumpable state removes an ordinary attachment route; it does not supersede every privileged access path or every LSM decision.
This is especially relevant on hosts where multiple services share a Unix account. Same UID is not automatically equivalent to unrestricted debugging authority once dumpable state and other ptrace controls are considered.
Procfs ownership changes expose the same state in another interface
Files below /proc/<pid> are normally owned by the process effective user and group. When dumpable is not 1, Linux changes that ownership to the applicable root identity described by procfs semantics.
This behavior reduces the usefulness of ordinary ownership as a route into sensitive per-process procfs entries after the process becomes non-dumpable. Access to individual procfs files can still have additional permission checks, mount options, namespace effects, and ptrace-style access modes.
The ownership transition is therefore not equivalent to hiding /proc/<pid>. The directory can remain visible, and procfs exposes many files with distinct access rules. The security claim should stay narrow: dumpable state changes ownership and participates in access checks; it does not make the process disappear from procfs.
User namespaces also affect which root identity owns these entries. Modern kernels account for mapped root identities in noninitial user namespaces rather than treating every case as initial-namespace UID 0.
A later reset to 1 reopens part of the inspection surface
A process may call PR_SET_DUMPABLE again with SUID_DUMP_USER. Doing so returns it to dumpable state 1 and restores the corresponding procfs ownership behavior to its effective credentials.
That transition can be operationally useful for controlled debugging, but it is also a policy change. Software that temporarily enables dumpability should treat the interval as a changed trust boundary rather than as a harmless diagnostic toggle.
The same caution applies to crash collection. Enabling dumpability to obtain diagnostic state can make memory inspection available through channels beyond the eventual core artifact, depending on the surrounding ptrace and LSM policy.
A robust design therefore separates the decision to retain diagnostic material from the decision to permit live process inspection. PR_SET_DUMPABLE influences both and cannot express those policies independently.
Memory secrecy requires controls beyond dumpable state
Non-dumpable state does not encrypt memory, erase secrets, prevent a process from voluntarily transmitting data, or constrain a sufficiently privileged actor that passes the relevant kernel checks. It also does not replace restrictions on inherited descriptors, IPC endpoints, logs, or application-level diagnostic interfaces.
Core dumps have their own scope controls as well. Linux provides mechanisms such as MADV_DONTDUMP and /proc/<pid>/coredump_filter for deciding which mappings participate in a dump when dumping is otherwise permitted. Those mechanisms address dump contents rather than the broader inspection boundary controlled by dumpable state.
The architectural consequence is a useful asymmetry: one bit of process state affects several debugging-oriented surfaces, yet each surface retains independent policy around it. Setting PR_SET_DUMPABLE to 0 can narrow ptrace attachment, core generation, and procfs ownership exposure at once, but a security design still has to account for privileged tracers, namespace policy, LSM restrictions, and every separate channel through which process data can leave the address space.