Question 1

What does systemd sandboxing actually do?

Accepted Answer

systemd can confine a service with a set of directives that sharply limit what a compromised process can touch: NoNewPrivileges stops privilege escalation, ProtectSystem makes most of the filesystem read-only, ProtectHome hides home directories, PrivateTmp gives an isolated /tmp, and ReadWritePaths whitelists only the directories the service legitimately needs. They are free to add and dramatically shrink the blast radius if the service is exploited.

Question 2

Why does a service need a restart policy?

Accepted Answer

Without Restart=always (or on-failure), a service that crashes simply stays down, and nobody is notified. Adding a restart policy with a RestartSec delay turns a transient crash into a brief blip the supervisor recovers from automatically. It is the difference between a service that is running and one that stays running.

Question 3

Should my service run as root?

Accepted Answer

Almost never. If the unit has no User= it runs as root, so a compromise of the process is root on the host. Run it as a dedicated unprivileged user with only the access it needs. Combined with the sandboxing directives, this is the core of hardening a systemd service.

Operate your backend.

Control production changes.

Tools for application teams.

Company and product information.

Analyze a systemd unit.

root, unsandboxed, and unwatched

Keep permissions explicit. Keep services running.