Em qua., 5 de jun. de 2024 12:56, Laurent Bercot <[email protected]> escreveu:
Honestly, I'd rather document in the source that the NotifyAccess > option > should be changed. The default seems very unnecessarily restrictive . > Agreed, and after looking on Repology, it seems there are still stable distros using systemd without MAINPID= support, so the current design is more portable. The reasoning for 'main' being the default is because NOTIFY_SOCKET is usually abstract (and therefore, world writable), meaning the daemon's children can potentially misuse the socket even if you change UIDs. Unfortunately I don't see a single way of addressing this that works with all versions of systemd currently in use, and having seen systemd discussions online, I know someone will bring it up as a negative for this tool even if it's not very realistic and ultimately caused by systemd deciding to use a Linux feature and using more Linux features when said feature turns out to be inadequate. Maybe the most portable way for sdnotify-wrapper to work is setting Type=forking and writing a PID file once we get a newline; hey, it'd be compatible with sysvinit too! I'd also consider shipping, or linking to, versions that rely on dependencies more likely to be installed on systemd machines; I've seen a Python version in the wild, and I can think of a sh version. Sure, it doesn't fit the "small" principle of Skarnet.org, but they'd be far easier to install and distribute (for instance, on an Ubuntu 20.04 machine, I had to backport a newer skalibs to test this patch). It would ultimately make the s6 notification protocol a more realistic option for third-party software. > > >If only there was an easy, portable way of ensuring only a process, its > >descendants, or trusted local services had access to the communication > >channel for readiness notification, without a central registry of > >everything running in the system... > > Preach. > My favorite part of the sd_notify protocol is the BARRIER directive. After exchanging fds with the server, it's essentially an ad hoc reimplementation of the s6 notification protocol except you don't check if it wrote anything back, removing the simplest form of error checking. Not even s6-notifywhenup was safe from Greenspun's tenth rule. >
