Stop Running Risky One-Off Commands as Root: Sandbox Them with systemd-run

If you’ve ever run a one-off command like this on a production box: sudo bash suspicious-script.sh …you already know the risk: it has your full filesystem, full network, full privileges, and no guardrails. For long-running services, we usually harden unit files. But for ad-hoc commands , people often skip safety. This is where systemd-run is underrated: it lets you launch a transient unit with hardening flags and resource limits without writing a permanent service file . In this guide, I’ll show a practical pattern you can reuse. Why systemd-run for one-off tasks? systemd-run creates transient .service or .scope units and passes normal unit properties via -p/--property . That means you can apply the same controls you’d use in hardened service files, including: Filesystem restrictions ( ProtectSystem , ProtectHome , ReadWritePaths ) Privilege hardening ( NoNewPrivileges ) Namespace isolation ( PrivateTmp ) Resource caps ( MemoryMax , CPUQuota ) This gives you a “safer blast radius” for