std.process.dropPrivileges in Zig 0.12.0 does not clear environment credentials

Answer: the application must scrub the environment

In Zig 0.12.0, std.process.dropPrivileges performs only the POSIX credential transition (setgroups, then setgid, then setuid). It does not touch the process environment, so any environment variable that held a secret or token remains readable after the call.

Confirmed facts

• The function wraps the setgroups, setgid and setuid syscalls; no code accesses or modifies environ.
• Environment variables reside in the process’s memory space; changing uid/gid does not affect their contents.
• An expired token is invalid regardless of the process’s privileges; the privilege drop does not change its validity.
• A stale‑but‑still‑valid token remains usable by the now‑unprivileged process and by any children it spawns.

Likely rationale

Zig’s standard library follows a thin‑wrapper philosophy: it avoids hidden policy such as guessing which variables are secrets, because that judgment is application‑specific and could break legitimate post‑drop configuration reads.

Steps for this case

1. During the privileged phase, read any needed secret into application memory (e.g., const token = std.posix.getenv(\"API_TOKEN\") orelse return error.MissingSecret;).
2. Before calling dropPrivileges, unset or overwrite the variable: std.posix.unsetenv(\"API_TOKEN\"); (overwriting first can help if the underlying storage might retain a copy).
3. If you have already forked worker processes, ensure they do not inherit the secret; either fork after scrubbing or arrange for the workers to reload secrets from a safe source.
4. Call std.process.dropPrivileges(uid, gid);.

Missing diagnostic detail: Have you already spawned any child processes before the environment scrub? If yes, the recommendation changes because those children retain the original environment and you must address them separately (e.g., by restarting them after the drop or by ensuring they never received the secret).