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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
