Post #1103732
2026-04-09 16:07 UTC
Replies (3)
-
@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.
-
@mia@shrimptest.0x0.st 2026-04-09 16:13
@ska@social.treehouse.systems there’s posix ipc and sysv ipc and both kinda suck, and then there’s user space things like dbus which everyone just puts up with(?!?!?), and somehow we try to do security like this this is MADNESS