content: Add new post: "proc(5) hidepid=2 and systemd"

1 files changed, 35 insertions, 0 deletions

diff --git a/content/12/index.md b/content/12/index.md
new file mode 100644
index 0000000..d9bb3a2
--- /dev/null
+++ b/content/12/index.md
@@ -0,0 +1,35 @@
++++
+date = 2021-10-27T12:46:24+02:00
+title = "proc(5) hidepid=2 and systemd"
+
+[taxonomies]
+tags = ["TIL", "systemd"]
++++
+
+A couple of days ago I turned on
+[`hidepid=2`](https://manpages.debian.org/bullseye/manpages/proc.5.en.html#hidepid)
+for the `/proc` mount on my desktop PC. Today I saw the `systemd-userdbd`
+service failing on bootup, and realized that it had been failing to start for a
+few days. Aside from the fact that there really should be a well-supported and
+easy way to notify administrators of failing units, this obviously needed some
+investigation.
+
+`systemctl status systemd-userdbd.service` wasn't very helpful, but `journalctl`
+had the specific error:
+```
+[..] spawning /lib/systemd/systemd-userdbd: Read-only file system
+```
+
+I didn't immediately jump to the conclusion that this had to do with enabling
+`hidepid=2`. After all, why would that result in a read-only file system?
+Investigating a failure very early on in boot is a pain, so instead of wasting
+my time on that I took to GitHub issues.
+
+As it turns out, `hidepid=` is just 
+[not supported](https://github.com/systemd/systemd/issues/12955#issuecomment-508490893)
+[at all](https://github.com/systemd/systemd/issues/20848#issuecomment-930185888)
+in systemd. This doesn't seem to be pointed out anywhere, and I certainly was
+not aware of it before. Services can set
+[`ProtectProc=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=),
+but there doesn't seem to be a clean way of restricting /proc for unprivileged
+users like a global `hidepid=2` did. I've removed the option for now.