DynamicUser and the StateDirectory pitfall

2026-08-27T00:00:00+00:00

Every backend on this platform is a Rust binary launched through systemd, and every unit is a locked-down DynamicUser=yes</code> service. DynamicUser is great: each instance gets a transient, unprivileged uid/gid that exists for the life of the unit and vanishes when it stops, taking account capabilities with it. No shared accounts, no shell, nothing to leak between services.</p>

But there is a trap. A dynamically allocated user does not</strong> automatically get a home directory it can write to, and a naive Persistent=true</code> does not give you a readable storage root either. A Rust service calling std::fs::create_dir_all("/var/lib/huck-storage")</code> under such a unit fails with Permission denied</code>, because the unit’s user cannot touch /var/lib</code> at all once ProtectSystem=strict</code> is on. The directory must be provisioned and owned</em> by the unit before the process starts.</p>

The one-liner: StateDirectory</h2> The correct answer is systemd’s StateDirectory=</code>:</p> [Service] DynamicUser=yes StateDirectory=huck-storage Environment=HUCK_STATE_DIR=/var/lib/huck-storage </code></pre> StateDirectory=</code> makes systemd create /var/lib/huck-storage</code>, chown it to the dynamic user, and make it writable — all before ExecStart</code> runs. That single directive is what lets an otherwise fully-unprivileged process own its own persistent state.</p> The pitfall we hit twice</h2> The subtlety is that a StateDirectory</code> is per-unit</strong>. The moment two services share a path, systemd refuses to start the second one: the directory is already owned by another dynamic user, and the hardened unit gets a “permission denied” on boot. That is why each service here declares its own directory (huck-config</code>, huck-storage</code>, …) rather than a shared /var/lib/huck</code>.</p> It is also why the state path must be passed explicitly via Environment=</code>. DynamicUser does not expand ~</code> to your new uid reliably, and relying on $HOME</code> in a hardened unit is fragile. One explicit variable, one matching StateDirectory=</code>, and the process always knows where it may write.</p> Atomic writes</h2> Ownership solved, the remaining habit worth keeping is writing state carefully. Our persistence pattern is load-at-boot plus write-on-mutation:</p> std::fs::write(&tmp, &bytes)?; // state.json.tmp std::fs::rename(&tmp, &path)?; // atomic over state.json </code></pre> Writing to a temp file then rename</code>-ing over the target avoids a torn file if the unit is killed mid-write — rename</code> is atomic on the same filesystem, so the service never observes a half-written state.json.</p> The rule of thumb: give every DynamicUser unit its own StateDirectory</code>, hand it the path through an explicit variable, and write state atomically. That is the whole lock-down without the surprise.</p>

Bringing rust.solutions online

2026-08-26T00:00:00+00:00

This site is now live. Rather than a monolithic app, the domain runs on a small edge pattern that keeps every subdomain independently deployable.</p>

The edge pattern</h2>

A single server block owns rust.solutions</code> and *.rust.solutions</code>. A map</code> directive resolves each hostname to a loopback backend:</p>

map $host $huck_backend {
    rust.solutions   http://127.0.0.1:13008;
    blog.rust.solutions http://127.0.0.1:13013;
    default "";
}
</code></pre>
Unknown subdomains fall through to an empty string and get rejected with
a 404 before any proxying happens. Known ones are forwarded to whatever
listens on their assigned port — a static file server today, a Rust
service tomorrow.</p>
Why loopback ports</h2>
Each backend binds to 127.0.0.1</code> only. Nothing is directly reachable
from the internet; the TLS-terminating edge is the single front door.
Adding a service means binding one port and adding one map line.</p>
The static build</h2>
The apex is generated by Zola</a>: no JavaScript,
no client framework, one stylesheet, HTML minified at build time. The
whole page budget fits comfortably in a few kilobytes.</p>
That’s the whole trick: boring components, clear seams between them.</p>

rust.solutions

DynamicUser and the StateDirectory pitfall

Bringing rust.solutions online

Why loopback ports</h2>
Each backend binds to `127.0.0.1</code> only. Nothing is directly reachable from the internet; the TLS-terminating edge is the single front door. Adding a service means binding one port and adding one map line.</p>`

`The static build</h2> The apex is generated by Zola</a>: no JavaScript, no client framework, one stylesheet, HTML minified at build time. The whole page budget fits comfortably in a few kilobytes.</p> That’s the whole trick: boring components, clear seams between them.</p>`

rust.solutions

DynamicUser and the StateDirectory pitfall

Bringing rust.solutions online

Why loopback ports</h2> Each backend binds to 127.0.0.1</code> only. Nothing is directly reachable from the internet; the TLS-terminating edge is the single front door. Adding a service means binding one port and adding one map line.</p>

The static build</h2> The apex is generated by Zola</a>: no JavaScript, no client framework, one stylesheet, HTML minified at build time. The whole page budget fits comfortably in a few kilobytes.</p> That’s the whole trick: boring components, clear seams between them.</p>

Why loopback ports</h2>
Each backend binds to `127.0.0.1</code> only. Nothing is directly reachable from the internet; the TLS-terminating edge is the single front door. Adding a service means binding one port and adding one map line.</p>`

`The static build</h2> The apex is generated by Zola</a>: no JavaScript, no client framework, one stylesheet, HTML minified at build time. The whole page budget fits comfortably in a few kilobytes.</p> That’s the whole trick: boring components, clear seams between them.</p>`