This utility creates a RAM-backed block device, formats it as HFS+, and mounts it at:

/tmp/SecureScratch

On macOS, /tmp resolves to /private/tmp, so tools such as mount and df may report the filesystem at:

/private/tmp/SecureScratch

The utility is intended to provide temporary working space for sensitive data without deliberately placing that data on the Mac’s persistent filesystem.

What does "secure" mean here?

The storage is volatile, which provides several useful security properties:

  • Its contents disappear after the RAM disk is detached or the machine is restarted.
  • Files are not intentionally written to the underlying SSD.
  • Access to the mount point is restricted to the current user.
  • The filesystem is mounted with nodev, nosuid, and noexec.
  • It is useful for temporary decrypted files, build artefacts, extracted sensitive material, document processing, and intermediate data.

However, a RAM disk is not automatically secure against every threat:

  • Files are not encrypted while resident in memory.
  • Processes with sufficient privileges may still read them.
  • Memory contents may potentially appear in swap, crash dumps, or other operating-system artefacts.
  • Applications may create autosave files, caches, thumbnails, logs, or recovery data elsewhere.
  • A crash, shutdown, restart, or forced detach destroys the contents immediately.
  • Backup and recovery are intentionally unavailable.

Security boundary: This is therefore a control for reducing accidental persistence—not a secrets vault, sandbox, encrypted memory system, or complete data-loss-prevention mechanism.

Bash-based usage

Create a 24 GiB RAM disk:

./secure_volatile_scratch_space.sh mount --size-in-gb 24

Inspect its status:

./secure_volatile_scratch_space.sh status

Print the underlying device path:

./secure_volatile_scratch_space.sh device

Unmount the filesystem and destroy the RAM-backed device:

./secure_volatile_scratch_space.sh unmount

Force teardown when an ordinary unmount cannot complete:

./secure_volatile_scratch_space.sh unmount --force

Force mode should be used only after closing applications and processes that may still be accessing the scratch space.

Why I built it

I designed the security model around this utility to reduce the accidental persistence of temporary sensitive data.

It is particularly useful in workflows where writing customer or regulated working data to persistent local storage could place you in breach of contractual data-handling requirements.

The RAM disk does not replace endpoint encryption, least-privilege access, short-lived credentials, application controls, audit logging, or approved data-handling procedures. It provides a constrained volatile workspace that can be created for a task and destroyed immediately afterwards.

Platform support

This implementation is specifically for macOS.

The equivalent design differs by operating system:

Linux

Linux can use a native tmpfs mount with restrictive permissions and mount options such as:

nodev,nosuid,noexec

Where the running kernel supports it, the Linux implementation can additionally enforce noswap. A robust utility should detect whether strict no-swap operation is available and fail closed when strict enforcement has been requested but cannot be provided.

Windows

Windows requires additional design decisions.

Two practical options are:

  • Use a WSL2 tmpfs when the entire processing workflow can remain inside WSL.
  • Use a separately reviewed PowerShell implementation backed by an organisationally approved and cryptographically signed RAM-disk driver for native Windows applications.

The Windows implementation should not be assumed to provide guarantees identical to macOS or Linux. Windows paging, hibernation, crash dumps, application caches, driver trust, and endpoint configuration must be considered separately.