Em qua., 5 de jun. de 2024 12:56, Laurent Bercot <ska-skaware_at_skarnet.org>
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.
>
Received on Wed Jun 05 2024 - 22:30:17 CEST