Safe Temporary Files and Lock Directories

Bash scripts frequently need temporary storage — intermediate results, lock markers, staging areas. But creating temp files carelessly opens serious vulnerabilities.

• Race conditions: Another process can predict your filename and create the file first, redirecting your writes.
• Symlink attacks: An attacker creates a symlink at your expected path pointing to a sensitive file like /etc/passwd.
• Leftover files: If a script crashes, temp files pile up and may expose sensitive data.

The two core tools that eliminate these problems are mktemp and flock. This lesson shows you how to use both safely and defensively.

mktemp creates a temporary file with a random, unpredictable name and returns its path. It atomically creates the file, so no other process can grab the name first.

• Syntax: mktemp [TEMPLATE] — the template must end in at least three X characters.
• Each X is replaced by a random character, producing a unique name like /tmp/script.aB3kQz.
• The file is created with permissions 0600 (readable only by the owner) automatically.

Always capture the returned path into a variable immediately so you can reference and clean it up later.

If your script exits unexpectedly — due to an error, a signal, or set -e triggering — temp files will be left behind unless you register a cleanup handler.

The trap built-in runs a command when the shell receives a signal or exits. The canonical pattern for temp file cleanup is:

• Register the trap immediately after creating the temp file.
• Trap on EXIT so cleanup runs on both normal and abnormal exit.
• Also trap INT and TERM if the script runs long or is interactive.

This guarantees no orphan files, even if the script is killed mid-execution.

Sometimes you need an entire directory for staging multiple files — for example, building an archive or extracting a tarball before processing. Use mktemp -d to create a secure temporary directory.

• The directory is created with permissions 0700 (owner-only access).
• Clean up with rm -rf in your trap — be careful to only remove the variable, never a hardcoded path.
• Use double-quoting and verify the variable is non-empty before calling rm -rf as an extra safety check.

Cron jobs, systemd timers, and manually triggered scripts can easily launch multiple instances of the same script simultaneously. This causes:

• Duplicate processing: The same database records or files are processed twice.
• Corrupted output: Two instances write to the same output file concurrently.
• Deadlocks or partial state: Both instances modify shared resources in an interleaved, unpredictable order.

The traditional fix was to write a PID file and check it on startup — but this approach has a race window between the check and the write. The correct modern solution is flock, which uses the kernel's advisory locking mechanism for a guaranteed race-free lock.

flock acquires an advisory lock on a file descriptor before running a command. The simplest usage wraps your entire script from the command line:

flock -n /var/lock/myscript.lock bash myscript.sh

• -n (non-blocking): exits immediately with status 1 if the lock is already held, rather than waiting.
• Without -n, flock blocks until the lock becomes available — useful for queuing.
• The lock file itself is just a marker; its content does not matter. It is safe to keep it between runs.
• When the process holding the lock exits, the kernel automatically releases it — no manual cleanup needed.

For locking within a script rather than wrapping it from outside, use exec to open a file descriptor and then call flock on that descriptor. This is the idiomatic pattern used in production scripts.

• exec 200>"$LOCKFILE" opens the file on descriptor 200 for writing (creating it if needed).
• flock -n 200 tries to lock descriptor 200 non-blocking.
• Because the lock is tied to the file descriptor (not the file name), it is released automatically when the shell process exits.
• Descriptor numbers 200-299 are conventionally used to avoid clashing with stdin/stdout/stderr.

Real defensive scripts need both: a lock to prevent concurrent runs and secure temp files for intermediate data. Here is the complete pattern combining both techniques:

• Acquire the lock first — before creating any temp files — so only one instance does any work at all.
• Create temp resources after the lock is confirmed.
• Register the trap immediately after creating temps so cleanup is guaranteed regardless of how the script exits.
• The lock file never goes in the temp directory — it must persist between runs so flock can reference it.

On systems where flock is unavailable (some embedded systems or network filesystems like NFS), you can use lock directories instead. mkdir is atomic on POSIX systems: it succeeds only if the directory does not already exist.

• Create the lock directory with mkdir /tmp/myscript.lock.d — if another instance already created it, mkdir fails immediately.
• Store metadata (like the PID) inside the directory for diagnostics.
• Always remove the directory in a trap on EXIT.
• Caveat: Unlike flock, a directory lock is NOT automatically released if the process is killed with -9 or the machine reboots — add a stale-lock detection check.

Sometimes you want to wait for a lock rather than fail immediately — but not wait forever. flock supports a timeout with the -w flag.

• flock -w 10 200 waits up to 10 seconds for the lock, then exits with status 1 if still unavailable.
• This is ideal for scripts that should queue behind a short-lived predecessor but give up if the predecessor is stuck.
• Combine -w with a meaningful error message that includes context — the lock file path and how long you waited — so operators can diagnose hangs quickly.

Before shipping any script that uses temp files or locking, run through this checklist:

• Use mktemp, never hardcoded paths — /tmp/myapp.tmp is predictable and exploitable.
• Capture the path immediately — TMPFILE=$(mktemp ...) before any other command.
• Register trap cleanup EXIT immediately after creation — not at the end of the script.
• Double-quote all variable uses — rm -f "$TMPFILE", never rm -f $TMPFILE.
• Prefer flock over PID files — kernel-managed, automatically released on crash.
• Use non-blocking -n by default — silent blocking locks hide performance problems.
• Put the lock file outside the temp directory — so it survives the cleanup trap.
• Test cleanup behavior — run your script and kill -9 it mid-execution; verify no leftover files remain (for flock-based scripts; directory locks need extra care).

A cron job runs every minute and processes a shared file. You want any new invocation to exit immediately with an error if a previous run is still active, without waiting. Which flock invocation correctly implements this?

In this lesson you learned the two essential tools for defensive resource management in Bash:

• mktemp creates unpredictable, securely-permissioned temporary files (0600) and directories (0700), eliminating race conditions and symlink attacks that plague hardcoded paths.
• trap cleanup EXIT guarantees temp file removal on any exit — normal, error-triggered, or signal-triggered — when registered immediately after creation.
• flock provides kernel-enforced advisory locking: use -n to fail fast on contention, -w N to wait with a timeout, and the exec 200>file pattern for in-script locking that the kernel releases automatically on process exit.
• Lock directories (mkdir) offer a portable fallback for environments where flock is unavailable, but require explicit stale-lock detection.
• Always keep the lock file outside the temp directory and double-quote every variable used in cleanup.

Combining mktemp + flock + trap gives you scripts that are safe against concurrent invocations, unpredictable crashes, and adversarial filesystem manipulation.