11.2.3.3 App Write Paths

App write paths are the specific directories an application genuinely needs write access to — logs, uploaded files, cache data — that must be deliberately identified and made writable through a volume or tmpfs mount when the rest of the container's filesystem is otherwise read-only.

Identifying an Application's Actual Write Needs

Reviewing what an application actually writes to during normal operation reveals exactly which paths need to remain writable.

docker run myapp:1.0
docker exec myapp lsof | grep WRITE

Reviewing this kind of output, or simply consulting the application's own documentation, helps identify the specific paths genuinely requiring write access.

Providing Exactly Those Paths as Writable Exceptions

Once identified, each genuinely needed write path is made writable through an appropriately chosen mount, while everything else remains read-only.

docker run \
  --read-only \
  --tmpfs /tmp \
  -v app-logs:/app/logs \
  -v app-uploads:/app/uploads \
  myapp:1.0

This configuration provides exactly the writable paths this particular application needs, with the rest of its filesystem remaining immutable.

Why Overly Broad Write Access Defeats the Purpose

Making an entire application directory writable, rather than just the specific subdirectories that actually need it, unnecessarily broadens what a compromised process could modify, undermining much of the benefit a read-only configuration is meant to provide.

docker run --read-only -v app-data:/app myapp:1.0

Mounting an entire /app directory as writable, rather than just its specific logs or uploads subdirectories, is considerably broader than most applications' actual write needs.

Documenting an Application's Write Path Requirements

Clearly documenting which paths a given application needs writable access to helps ensure this configuration is applied correctly and consistently wherever that application is deployed.

Required writable paths: /app/logs, /app/uploads, /tmp

Why App Write Paths Matter

Precisely identifying and scoping an application's actual writable needs, rather than broadly granting write access, is essential for getting the full security benefit of an otherwise read-only container filesystem configuration.