Good point. Check testing it is actually expected unix socket would be quite nice. Especially when the file sd-daemon.c implements sd_is_socket_unix function, but never uses it itself. libsystemd verifies this using socket_address_parse_unix or socket_address_parse_vsock in pid_notify_with_fds_internal.
All in all, I don't see any good reason, why shared functionality should be copy&pasted to every project. That is the worst long-term idea hindering maintenance of shared functionality. I have been part of project having a lot of copy&paste. It was quick to write, but hard to maintain afterwards. Shared libraries make sense even when they are small, especially when that small part is needed often. Which is exactly the case of sd_notify variants.
Reusing easy to read and with no dependencies except libc is still much better idea.
I think projects having bundled implementation should mark it somehow in their packages. Something like Provides: bundled(systemd/sd_notify) ? Or bundled(systemd-libs) ? I think such functionality should be searchable somehow in the repository. I think we should define how it should be marked in case of inline copy. bundled(systemd) seems a bit too strong, but according to Bundling specification in packaging guidelines [1].
I like idea in marked comment [2]. It might get even launcher-independent way of daemon to signal its readiness. We do not support alternatives to systemd, but I see no reason to prevent upstream project to reuse the same way for any alternative, which may use readiness signal from the service. Other distributions still allow other combinations. It would be much better to support alternative process managers from shared library than in each project itself.
PS: once again comments are marked as spam, when they simply disagree with systemd team stance, but are otherwise to the point. That unfortunately makes no constructive discussion possible on systemd upstream issues.
1. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling 2. https://github.com/systemd/systemd/issues/32028#issuecomment-2034099384
On 02. 04. 24 20:05, Kevin Kofler via devel wrote:
Lennart Poettering wrote:
It *literally* is just sending a text string "READY=1" in an AF_UNIX datagram to a socket whose path is provided to you in the $NOTIFY_SOCKET env var.
I see so many ways one can get this wrong. E.g., using some abstraction for the socket write that can also write to regular files, without checking that "$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU vulnerability), introducing an arbitrary file overwrite vulnerability.
Kevin Kofler