Even without root a service sees the whole disk and other people's home directories. systemd can close those off without touching the service's code.
Restrictions (in the Wiki) go on lines in the same [Service] section of the drop-in:
| Line | What it does |
|---|---|
ProtectSystem=strict |
the whole filesystem is read-only, except explicitly opened paths |
ProtectHome=yes |
the service cannot see /home or /root |
NoNewPrivileges=yes |
the process and its children cannot gain privileges (through sudo or setuid, for example) |
PrivateTmp=yes |
a private /tmp, separate from the shared one |
With ProtectSystem=strict the service cannot write even to /etc, and NoNewPrivileges=yes disables the setuid bit: sudo under such a process refuses. A service that only hands out ready files needs to write nowhere — the restrictions do not get in its way.
Close the disk and homes to the service
In the same lab-preview drop-in add restrictions: the whole filesystem read-only (ProtectSystem=strict), /home and /root hidden (ProtectHome=yes), privilege escalation forbidden (NoNewPrivileges=yes). After a restart the service must still serve the report on http://127.0.0.1:8095/q3.txt.
Goals · 0 of 3
- Make the disk read-only and hide home directories not done yet
- Forbid the service to gain privileges not done yet
- Keep the service answering requests not done yet
A service has ProtectSystem=strict. It tries to write a file to /etc. What happens?
-
ProtectSystem=strictmakes the disk read-only for root as well.systemd-run -p ProtectSystem=strict touch /etc/xanswers “Read-only file system”. -
A unit with
ProtectSystem=strictstarts fine; the block happens at the write, not at start. -
systemd does not redirect the path — it refuses the write. The file at
/etc/...is simply not created.
ProtectSystem=strict makes the whole filesystem read-only except explicitly opened paths, so a write to /etc is refused — even for root.