2026-04-09 16:07 UTC
Replies (2)
-
@navi@social.vlhl.dev 2026-04-09 16:13
@mia @ska i mean systemd wouldn't even need that if they just passed a pre-opened socket (assuming they *do* want the two way communication and fd-passing features) socketpair and keep it open, done, authentication by environmental capability the design choice of not doing that, and instead going with a socket path, was theirs, and theirs alone (NOTIFY_SOCKET is usually /run/systemd/notify, honestly i'm at least thankful they didn't hardcode that path on their spec)
-
@ska@social.treehouse.systems 2026-04-09 16:13
@mia@shrimptest.0x0.st It does. (getsockopt() with SO_PEERCRED, and you get the uid, gid and pid of the client.) But that's not useful here, because what systemd wants is a mechanism that's restricted to one unit; neither uid nor gid can be used for it, and pid isn't a good identifier since the notifier isn't necessarily the main process in the unit. There's an easy way to provide a communication channel to the unit only: the supervisor creates a pipe beforehand and passes the writing end to the unit. That's what s6 does. But of course, that would be way too simple for systemd, so here we are.