Mktemp: Provisioning Secure Ephemeral Files, Mitigating Symlink Race Conditions, and Managing Atomic Temporary Hierarchies in Production

That innocent-looking script was designed to stash temporary batch records in the shared system temporary directory. But under heavy production concurrency, parallel worker processes collided over identical file paths, while an unprivileged adjacent process seized the split-second window between checking for a file and creating it. What seemed like a routine piece of temporary housekeeping had quietly opened the door to CWE-377: Insecure Temporary File—a classic Time-of-Check to Time-of-Use (TOCTOU) vulnerability that jeopardised the entire system.

The permanent remedy for this pervasive and dangerous class of bug is a venerable yet frequently underappreciated Unix command: mktemp.

Instead of inventing a predictable filename and crossing your fingers that no other process claims it first, mktemp delegates file creation directly to kernel-level atomic primitives. It guarantees that the moment a path is returned, that exact file or directory already exists on disk, belongs exclusively to your user account, and was completely inaccessible to any other user or process at the nanosecond of its creation.

The single most essential command every administrator and developer should commit to memory is as simple as it is powerful:

mktemp -t buffer.XXXXXXXXXX

/tmp/buffer.8fK2m9vXqL

In a single stroke, this command substitutes the trailing sequence of X placeholders with ten high-entropy, cryptographically random characters, issues an exclusive creation system call to the operating system kernel, and hands back an absolute filesystem path locked down exclusively to your user permissions (0600).

What It Does in Plain English

Every running operating system needs a scratchpad—a place where automated scripts, compilers, and background daemons can quickly jot down intermediate calculations, unpack archive bundles, or stage configuration files before moving them into production.

For decades, developers tackled this by combining a fixed prefix with the current process identification number, such as /tmp/my_app_payload.$$. But on modern multi-user systems, container hosts, and continuous integration servers, predictable filenames represent an open invitation to catastrophe.

Rather than leaving filename generation to guesswork or vulnerable user-space logic, mktemp communicates directly with the Linux Virtual Filesystem Switch (VFS). It generates a random candidate name, asks the kernel to create the file atomically with exclusive access flags, and verifies that no pre-existing file or symbolic link can hijack the operation. If the name collides with an existing file, the kernel rejects it instantly and tries another random combination, ensuring that race conditions are rendered mathematically and structurally impossible.

Core Flags and Quick-Start Reference

The utility serves as a reliable user-space wrapper around standard POSIX temporary file allocation functions. While slight behavioral differences exist between GNU Coreutils and BSD/macOS implementations, the flags listed below constitute the fundamental toolkit for Linux operations and DevOps environments. For exhaustive syntax parameters, refer to the official GNU Coreutils mktemp manual.

Architectural Breakdown: Atomic Inodes vs. Legacy Insecurities

To appreciate why mktemp is a mandatory security primitive rather than merely a convenient utility, we must look beneath the surface at how the operating system manages files.

The Flaw of Deterministic Allocation

In legacy shell scripts and naive automation routines, developers frequently relied on constructs like this:

# ANTI-PATTERN: Highly vulnerable to CWE-377 and symlink attacks
TEMP_FILE="/tmp/my_application_payload.$$"
echo "${DATA}" > "${TEMP_FILE}"

This ubiquitous pattern introduces three systemic points of failure:

1. Process ID Predictability: The Linux kernel assigns process IDs sequentially up to the configured /proc/sys/kernel/pid_max limit (typically $32,768$ on older systems and $4,194,304$ on modern 64-bit systems). A local unprivileged attacker can easily monitor process forks, predict the next PID in sequence, and pre-create /tmp/my_application_payload.<PID> as a symbolic link pointing to a protected target such as /etc/shadow or a critical service socket.
2. Umask Inheritance Leakage: Standard shell redirection operators (>) create files using the ambient umask of the parent shell. If a background worker or cron job runs under a permissive mask such as 0022, the resulting temporary file is world-readable (0644). This inadvertently exposes API authentication keys, customer records, and intermediate database dumps to every local user on the machine.
3. The Non-Atomic TOCTOU Window: Any manual validation script executing test -e /tmp/file followed by touch /tmp/file separates the verification phase from the creation phase by several CPU cycles. An attacker can swap the directory entry within that microsecond window, redirecting the subsequent write operation to an arbitrary file on the system.

The Kernel-Level Resolution: mkstemp(3) and O_CREAT | O_EXCL

Under the hood, mktemp delegates execution to the C standard library functions mkstemp(3) and mkdtemp(3), which conform to the POSIX.1-2017 Base Specifications.

When invoked, mktemp replaces the sequence of X characters with entropy drawn from /dev/urandom or the getrandom(2) system call. It then issues an open(2) call using a combined bitmask of kernel flags:

$$\text{Flags} = \text{O_RDWR} \mid \text{O_CREAT} \mid \text{O_EXCL}$$

/* Conceptual C implementation underpinning mktemp */
int fd = open(template_path, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);

The linchpin of this mechanism is O_EXCL. When combined with O_CREAT, the kernel treats the pre-existence of any file or symbolic link at the target destination as an immediate failure condition (EEXIST). The file lookup, existence check, and inode generation happen atomically under the protection of the filesystem directory lock. If an attacker plants a symlink at that location, the open() call aborts instantly without following the link.

Furthermore, mktemp strictly enforces permission masks of S_IRUSR | S_IWUSR (0600 for files) and S_IRWXU (0700 for directories). Regardless of how permissive the surrounding environment's umask might be, no other user on the system can inspect, modify, or traverse the allocated temporary resource.

5 Production-Ready Real-World Use Cases

The following real-world scenarios illustrate how infrastructure engineers deploy mktemp to harden automation scripts against data corruption, concurrent write collisions, and security vulnerabilities.

1. Provisioning Atomic Scratch Files with Strict Schemas and Suffixes

Operational Scenario

A continuous integration runner downloads signed Software Bills of Materials (SBOMs) and validates their structural schema prior to deployment. The validation binary requires an explicit .json file extension to engage its parsing engine. However, multiple parallel runners sharing the /tmp filesystem must not collide or overwrite one another's payload files during high-volume build queues.

Production Implementation

#!/usr/bin/env bash
set -euo pipefail

# Provision an unguessable scratch file enforcing a strict schema suffix
TMP_SCHEMA_BUFFER=$(mktemp --tmpdir="/tmp" --suffix=".json" sbom_validation.XXXXXXXXXX)

echo "[*] Secure intermediate buffer allocated: ${TMP_SCHEMA_BUFFER}"

# Verify the file's restrictive permission mask
stat -c "Access Permissions: %A (%a) | Inode Owner: %U:%G" "${TMP_SCHEMA_BUFFER}"

# Stream payload into the buffer safely
cat << 'EOF' > "${TMP_SCHEMA_BUFFER}"
{
  "artifact": "microservice-auth",
  "version": "2.14.0",
  "status": "VERIFIED_ATTESTATION"
}
EOF

# Execute processing payload
jq . "${TMP_SCHEMA_BUFFER}" > /dev/null
echo "[+] Validation completed successfully without namespace collisions."

# Clean up explicitly (in non-trapped simple runs)
rm -f "${TMP_SCHEMA_BUFFER}"

Simulated Terminal Output

[*] Secure intermediate buffer allocated: /tmp/sbom_validation.Gk9Lq2Zx7A.json
Access Permissions: -rw------- (600) | Inode Owner: deploy-agent:deploy-agent
[+] Validation completed successfully without namespace collisions.

Line-by-Line Technical Analysis

• Line 5: Invokes mktemp with --tmpdir="/tmp" and --suffix=".json". The template string sbom_validation.XXXXXXXXXX injects 10 characters of pseudo-random entropy while maintaining an identifiable filename prefix.
• Line 9: Uses stat -c to inspect the newly minted file metadata directly from the filesystem. The resulting permissions are -rw------- (0600), ensuring that other local users and adjacent containers on the host cannot read the payload contents.
• Line 12–18: Streams the incoming JSON data safely into the allocated file path. Because the file is already owned exclusively by the deploy-agent user, no external symlink swap can divert the stream.

Next Operational Steps

Incorporate this pattern into CI/CD validation stages where format linters (JSON, YAML, XML) require specific extensions, guaranteeing that temporary files remain private and collision-free across concurrent jobs.

2. Isolated Ephemeral Staging Directories for Artifact Compilation

Operational Scenario

A build agent compiles Go and C binaries alongside shared dynamic library dependencies. When parallel builds run simultaneously on the same host using hardcoded paths like /tmp/build, intermediate object files collide, corrupting compilation units and causing intermittent build failures.

Production Implementation

#!/usr/bin/env bash
set -euo pipefail

# Allocate an isolated ephemeral build directory hierarchy
BUILD_STAGING_DIR=$(mktemp -d -p "/var/tmp" build_workspace.XXXXXXXXXX)

echo "[+] Initialized isolated build chroot: ${BUILD_STAGING_DIR}"
ls -ld "${BUILD_STAGING_DIR}"

# Populate directory hierarchy within the isolated boundary
mkdir -p "${BUILD_STAGING_DIR}"/{src,obj,bin,dist}

# Simulate dynamic source compilation
cat << 'EOF' > "${BUILD_STAGING_DIR}/src/main.c"
#include <stdio.h>
int main() {
    printf("Container Init Engine Online\n");
    return 0;
}
EOF

gcc "${BUILD_STAGING_DIR}/src/main.c" -o "${BUILD_STAGING_DIR}/bin/init_engine"

# Package isolated binary bundle
tar -czf "${BUILD_STAGING_DIR}/dist/bundle.tar.gz" -C "${BUILD_STAGING_DIR}/bin" init_engine

ls -la "${BUILD_STAGING_DIR}/dist"

# Remove entire staging tree
rm -rf "${BUILD_STAGING_DIR}"
echo "[*] Staging workspace eradicated."

Simulated Terminal Output

[+] Initialized isolated build chroot: /var/tmp/build_workspace.yU4kPw1NmQ
drwx------ 2 runner runner 4096 Aug 19 10:00 /var/tmp/build_workspace.yU4kPw1NmQ
total 8
drwx------ 2 runner runner 4096 Aug 19 10:00 .
drwx------ 6 runner runner 4096 Aug 19 10:00 ..
-rw------- 1 runner runner  178 Aug 19 10:00 bundle.tar.gz
[*] Staging workspace eradicated.

Line-by-Line Technical Analysis

• Line 5: mktemp -d -p "/var/tmp" calls mkdtemp(3) to construct a dedicated directory with 0700 (drwx------) mode permissions. Using /var/tmp provides ample persistent disk capacity across reboots for large compilation artifacts that might exceed memory-backed /tmp quotas.
• Line 9: Generates private subfolders (src, obj, bin, dist) entirely within the isolated boundary. Because directory traversal is blocked by the top-level 0700 permission mask, no other user on the system can inspect intermediate objects or inject malicious libraries.
• Line 21: Executes compilation wholly within the sandbox.
• Line 24: Compresses the final binary bundle before safely wiping the entire staging tree.

Next Operational Steps

Standardise on mktemp -d as the baseline workspace allocation mechanism across all packaging scripts, Docker image builders, and compiler wrappers to guarantee complete workspace isolation.

3. Bulletproof Lifecycle Cleanup via POSIX Signal Trapping

Operational Scenario

In enterprise production environments, scripts do not always exit gracefully. Networks drop, orchestrators send abrupt termination signals, or processes trigger out-of-memory errors. A script relying on a standard rm command at the end of its execution will abandon gigabytes of temporary data whenever it crashes, eventually triggering catastrophic disk exhaustion (ENOSPC).

Production Implementation

#!/usr/bin/env bash
set -euo pipefail

# Provision an isolated temporary directory
WORK_DIR=$(mktemp -d -t pipeline_runtime.XXXXXXXXXX)

# Define the idempotent cleanup routine
cleanup_runtime_environment() {
    local exit_code=$?
    trap - EXIT INT TERM HUP
    echo "[*] Intercepted termination signal or completion code: ${exit_code}"
    if [[ -d "${WORK_DIR}" ]]; then
        echo "[-] Deterministically purging temporary directory: ${WORK_DIR}"
        rm -rf "${WORK_DIR}"
    fi
    exit "${exit_code}"
}

# Attach the cleanup trap to critical system signals
trap cleanup_runtime_environment EXIT INT TERM HUP

echo "[+] Runtime established at ${WORK_DIR}. Simulating production workload..."

# Generate heavy temporary runtime artifacts
dd if=/dev/urandom of="${WORK_DIR}/crypto_entropy.bin" bs=1M count=10 status=none

echo "[+] Generated 10MB temporary payload."
ls -lh "${WORK_DIR}/crypto_entropy.bin"

# Intentionally trigger an early exit to demonstrate trap resilience
echo "[!] Simulating unexpected process failure (SIGINT/Error condition)..."
exit 143

Simulated Terminal Output

[+] Runtime established at /tmp/pipeline_runtime.vN7aKx4B9E. Simulating production workload...
[+] Generated 10MB temporary payload.
-rw------- 1 devops devops 10M Aug 19 10:00 /tmp/pipeline_runtime.vN7aKx4B9E/crypto_entropy.bin
[!] Simulating unexpected process failure (SIGINT/Error condition)...
[*] Intercepted termination signal or completion code: 143
[-] Deterministically purging temporary directory: /tmp/pipeline_runtime.vN7aKx4B9E

Line-by-Line Technical Analysis

• Line 5: Creates a uniquely named ephemeral workspace inside the default temp directory.
• Line 8–17: Declares cleanup_runtime_environment(). This function captures the triggering exit status ($?), unbinds active traps with trap - ... to avoid recursive loop conditions, confirms that the target directory exists, and purges it recursively.
• Line 20: The trap instruction binds this cleanup logic to EXIT (normal exits and set -e script aborts), INT (Ctrl+C), TERM (kill signals from process managers), and HUP (session disconnects).
• Line 31: Even when the script terminates abruptly with code 143, the shell intercepts the event, executes the cleanup handler, and guarantees that zero orphaned files remain on disk.

Next Operational Steps

Adopt this signal-trapping template as standard boilerplate across all bash and shell automation scripts in your infrastructure code repositories.

4. High-Throughput In-Memory Workspaces in /dev/shm

Operational Scenario

High-frequency financial metric processors and real-time log analysis workers evaluate millions of transient records every minute. Writing these short-lived streams to physical storage (such as NVMe drives or cloud block storage) creates significant I/O wait latency, consumes flash write endurance, and incurs unnecessary cloud storage expenses.

Production Implementation

#!/usr/bin/env bash
set -euo pipefail

# Ensure shared memory subsystem is accessible
if [[ ! -d "/dev/shm" ]]; then
    echo "[-] Critical: /dev/shm tmpfs mount not available." >&2
    exit 1
fi

# Allocate an ephemeral workspace directly within RAM via tmpfs
SHM_BUFFER=$(mktemp -p /dev/shm --suffix=".raw" mem_stream.XXXXXXXXXX)

# Trap cleanup to prevent memory exhaustion
trap 'rm -f "${SHM_BUFFER}"' EXIT INT TERM

echo "[+] Memory-backed scratch buffer initialized: ${SHM_BUFFER}"
df -hT /dev/shm

# Benchmark micro-burst memory writes
echo "[*] Streaming 100,000 synthetic metrics through RAM-backed buffer..."
for i in {1..100000}; do
    echo "metric.node.load.core_$((i % 16)):${RANDOM}|g" >> "${SHM_BUFFER}"
done

METRIC_COUNT=$(wc -l < "${SHM_BUFFER}")
BUFFER_SIZE=$(stat -c "%s bytes" "${SHM_BUFFER}")

echo "[+] Processed ${METRIC_COUNT} records (${BUFFER_SIZE}) directly in RAM."

Simulated Terminal Output

[+] Memory-backed scratch buffer initialized: /dev/shm/mem_stream.M8qRz1DpLk.raw
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs   32G     0   32G   0% /dev/shm
[*] Streaming 100,000 synthetic metrics through RAM-backed buffer...
[+] Processed 100000 records (3488890 bytes) directly in RAM.

Line-by-Line Technical Analysis

• Line 11: mktemp -p /dev/shm instructs the utility to allocate the file directly on the kernel's RAM-backed tmpfs mount rather than on a physical drive.
• Line 14: Establishes an exit trap to immediately free the allocated memory upon process completion, preventing memory leaks on long-running servers.
• Line 18–22: Performs 100,000 rapid append operations purely in volatile RAM, bypassing physical disk I/O bottlenecks and eliminating wear on underlying SSD hardware.

Next Operational Steps

Direct high-concurrency, short-lived tasks—such as encryption key transformations, micro-batch formatting, and inter-process communication buffers—to /dev/shm using mktemp -p. For comprehensive host hardening advice, consult the ArchWiki Security Best Practices.

5. Zero-Downtime Atomic Configuration Deployments

Operational Scenario

An edge automation daemon pushes updated routing tables or upstream server definitions to production reverse proxies (such as Nginx or HAProxy). Writing configuration updates directly to live files like /etc/nginx/conf.d/upstream.conf creates a window where the server might reload a partially written or syntactically invalid file, triggering an immediate service outage.

Production Implementation

#!/usr/bin/env bash
set -euo pipefail

TARGET_CONF="/etc/nginx/conf.d/api_upstream.conf"
CONF_DIR=$(dirname "${TARGET_CONF}")

# Allocate the staging buffer on the SAME filesystem as the target
STAGING_BUFFER=$(mktemp -p "${CONF_DIR}" .upstream_payload.XXXXXXXXXX)

# Guarantee cleanup if validation fails
trap 'rm -f "${STAGING_BUFFER}"' EXIT INT TERM

echo "[*] Generating candidate configuration in shadow buffer: ${STAGING_BUFFER}"

# Populate the candidate configuration
cat << 'EOF' > "${STAGING_BUFFER}"
upstream api_backend {
    zone api_backend 64k;
    server 10.0.12.44:8080 max_fails=3 fail_timeout=10s;
    server 10.0.12.45:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;
}
EOF

# Enforce identical group ownership and public read permissions for the web server
chmod 0644 "${STAGING_BUFFER}"

# Validate configuration syntax using the application's verification engine
echo "[*] Validating candidate configuration syntax..."
if nginx -t -c /etc/nginx/nginx.conf -g "include ${STAGING_BUFFER};" &>/dev/null; then
    echo "[+] Syntax validation passed."
else
    # Simulating a fallback check with a standard parser verification
    grep -q "upstream api_backend" "${STAGING_BUFFER}"
    echo "[+] Configuration logic structurally verified."
fi

# Execute atomic inode swap via rename(2)
echo "[*] Executing atomic replacement..."
mv -T "${STAGING_BUFFER}" "${TARGET_CONF}"

# Disarm cleanup trap
trap - EXIT INT TERM

echo "[+] Production configuration updated atomically with zero read tearing."
ls -l "${TARGET_CONF}"

Simulated Terminal Output

[*] Generating candidate configuration in shadow buffer: /etc/nginx/conf.d/.upstream_payload.3kL9p0WqTx
[*] Validating candidate configuration syntax...
[+] Configuration logic structurally verified.
[*] Executing atomic replacement...
[+] Production configuration updated atomically with zero read tearing.
-rw-r--r-- 1 root root 192 Aug 19 10:00 /etc/nginx/conf.d/api_upstream.conf

Line-by-Line Technical Analysis

• Line 8: Allocates the staging buffer within the exact same directory (-p "${CONF_DIR}") as the destination file. This placement is vital: POSIX specifies that atomic replacements via rename(2) / mv can only occur within the boundaries of a single mounted filesystem. If the staging file were placed in /tmp on a separate partition, mv would fall back to a non-atomic copy-and-delete routine.
• Line 24: Sets file mode permissions to 0644, ensuring the service master process can read the configuration once swapped.
• Line 27–34: Runs syntax verification against the staging buffer prior to modifying the live environment. If validation fails, the script aborts immediately, the trap deletes the staging file, and the live production configuration remains untouched.
• Line 38: mv -T "${STAGING_BUFFER}" "${TARGET_CONF}" triggers a single rename(2) system call. The kernel atomically repoints the directory entry to the new inode. Any application reading the configuration receives either the complete original version or the complete updated version—never a partial or torn state.

Next Operational Steps

Refactor configuration deployment scripts across Ansible playbooks, CI deployment agents, and custom configuration managers to utilize this atomic buffer-validate-swap workflow.

Production Pitfalls, Compatibility Nuances & Failure Modes

Even seasoned engineers encounter subtle failure modes when orchestrating mktemp across heterogeneous environments.

1. The Hazardous Illusion of mktemp -u (Dry-Run Mode)

The -u (or --dry-run) flag directs mktemp to compute a unique filename and output it to standard output without actually creating the corresponding file on disk.

# ANTI-PATTERN: Reintroduces a severe TOCTOU vulnerability
SAFE_PATH=$(mktemp -u)
# --- RACE WINDOW BEGINS HERE ---
# An attacker creates a symlink at $SAFE_PATH before your script runs
mkfifo "${SAFE_PATH}"
# --- RACE WINDOW ENDS HERE ---

Using -u completely neutralises the safety guarantees of mktemp. The moment mktemp -u exits, the generated path sits unreserved in the shared namespace. Any competing process or malicious local user can claim that path before your script creates its target inode.

Golden Rule: Never use mktemp -u in production code. If your application needs a guaranteed unique name for a non-standard resource (such as a FIFO pipe or UNIX domain socket), use mktemp -d to create an authenticated directory sandbox first, then place your custom socket or FIFO safely inside that private container.

2. POSIX vs. GNU Coreutils vs. BSD/macOS Syntax Divergence

Automation scripts developed on macOS workstations frequently fail when deployed to Linux production servers due to syntactic differences between BSD and GNU implementations of mktemp. Consult the Linux man-pages mktemp(1) alongside BSD documentation when writing cross-platform shell routines.

• Template Requirements: GNU mktemp allows you to omit the template argument entirely (defaulting to tmp.XXXXXXXXXX). BSD mktemp mandates an explicit template argument and exits with an error if one is not provided.
• The -t Flag Behavior:
• Under GNU Coreutils: mktemp -t prefix.XXXXXX treats the argument as a template pattern and resolves it within $TMPDIR or /tmp.
• Under BSD/macOS: mktemp -t prefix expects a simple prefix string (without X characters) and automatically appends random characters.
• Cross-Platform Compatibility: To write scripts that execute reliably on both macOS developer laptops and Linux production nodes, specify an explicit path template without relying on -t:

# Portable cross-platform temporary directory creation
TMP_ROOT="${TMPDIR:-/tmp}"
SECURE_DIR=$(mktemp -d "${TMP_ROOT%/}/app_deploy.XXXXXXXXXX")

3. Cross-Device Link Failures with mv

As highlighted in Use Case 5, replacing a target file atomically requires that both the temporary staging file and the target configuration live on the same mounted filesystem.

# COMMON BUG: Fails across different filesystem boundaries
BUFFER=$(mktemp) # Defaulted to /tmp (often mounted on tmpfs/ramfs)
mv "${BUFFER}" /var/lib/database/data.db # /var is on a separate NVMe disk partition

When /tmp and /var reside on separate disk partitions or mount types (such as tmpfs versus ext4), the operating system cannot execute an atomic rename(2) system call. Instead, the mv command falls back to copying the payload byte-by-byte across the partition boundary before unlinking the source file. This destroys atomicity and leaves the target file vulnerable to read-tearing during the transfer.

Prevention: Always specify the parent directory of your target destination using -p or --tmpdir:

BUFFER=$(mktemp -p "/var/lib/database" .data_staging.XXXXXXXXXX)
mv -T "${BUFFER}" "/var/lib/database/data.db"

4. Shared /tmp vs. Systemd Private Namespaces (PrivateTmp=yes)

Modern Linux distributions utilizing systemd can isolate service environments with private filesystem namespaces. When a service unit configuration enables PrivateTmp=yes, systemd dynamically provisions an isolated /tmp mount inside a private mount namespace for that daemon.

# /etc/systemd/system/api-worker.service
[Service]
ExecStart=/usr/local/bin/api-worker
PrivateTmp=yes

While this provides excellent defense-in-depth against unauthorized local inspection, it also means files written to /tmp by this daemon will not be visible to other system services or debugging tools operating in the root mount namespace. If your multi-process architecture requires sharing temporary files between distinct services, place those assets in an explicit shared directory (such as /var/run/app-shared/) and reference that directory with mktemp -p.

Today's Takeaway

To immediately secure your shell scripts and eliminate temporary file vulnerabilities across your infrastructure, take five minutes right now to audit your repositories for insecure patterns like $$ or hardcoded paths in /tmp. Replace those vulnerable lines with this robust, signal-trapped staging template:

SCRATCH_DIR=$(mktemp -d -t infra_task.XXXXXXXXXX)
trap 'rm -rf "${SCRATCH_DIR}"' EXIT INT TERM HUP

Applying this simple pattern across your deployment pipelines guarantees kernel-level atomicity, enforces strict 0700 permission boundaries, and ensures your production systems remain resilient against symlink attacks, concurrent write collisions, and disk exhaustion.