On Di, 02.04.24 14:04, Petr Menšík (pemensik@xxxxxxxxxx) wrote:I am not convinced dlopen will it make secure in the end. I am not sure this is a good solution. dlopen makes those dependencies non-obvious from packaging side and non-visible from ldd or similar checking programs. I think it should be considered to offer more than one dynamic library.It was considered. To the point that a decade ago, libsystemd originally was split up. But it was awful to maintain. But let's not repeat this discussion here. Read up here: https://github.com/systemd/systemd/issues/32028
Oh, I hate the way discussions are moderated at systemd upstream.
I would prefer to discuss here.
It appears you do not want to make it simple to use just notify lib. But luckily it does not have to be maintained by systemd team. Yes, the protocol is trivial. But it still needs to handle conditions when it does not run under systemd. When it does, but error occurs. While number of lines required are very low, it would have need to be duplicated many times in many services. More or less the same code.
It is apparent either everyone will implement it themselves or systemd-independent project needs to provide just limited sd_notify shared library. At least it needs documentation. Indication it implements sd_notify in some way is nice to have bonus.
Because the number of applications solving the same problem is rather high. It is not issue to be solved in about 3 projects. There are dozens of daemons, which should implement the same functionality. Common base even with a tiny library still makes a sense to me. Especially if most of them linked unnecessarily to libsystemd and thought that was the best option.For example most services I maintain links to libsystemd just because it wants sd_notify calls in their services. Without any proof I would expect quite many services would have similar problem. Could be perhaps libsystemd broken into few more dynamic linked libraries? I somehow doubt any kind of compression is needed for sd_notify calls. Could be even smaller library libsystemd-notify linked from libsystemd, which would allow end applications to explicitly declare they need more limited set of functions?Why link? I'd really just suggest people to implement the trivial client on their own. It's a trivial protocol for a reason: so that people can implement it natively in their language and framwork without bothering with our upstream libsystemd.
use libsystemd if you link against it anways and hack in C, or if you really don't are about the extra dep for a single function, but otherwise, why would you use the lib? 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. Anyone with a moderate understanding of UNIX APIs should be able to hack that up in a a few lines of code. It's a protocol I can summarize and explain in *one* frickin' sentence.
Yes, I admit, it is simple line oriented protocol. But you need to get notify socket path, handle failures when opening it. You need to know what to write there, so also documentation is needed. Man page for sd_notify is nice. Implementation of sd_notifyf() function would not be trivial. While it is not difficult to get right, it does not make sense to have over 15 different implementations, when it can share the same code. When you want to include also error messages, it certainly becomes more than few lines.
Function pid_notify_with_fds_internal from ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as suggested. Should I ask why, if not necessary? It seems whole sd-daemon.c has 775 lines, which would be nice to have separate library. Things missing are some helpers. Socket activation is not as needed as core sd_notify, but might be a good addition. Still needs just environment and pointer to ints. No unwanted dependencies, I think that would make a nice standalone shared library. It provides everything I would need in common service.
sshd upstream understood this btw: https://bugzilla.mindrot.org/show_bug.cgi?id=2641 Lennart -- Lennart Poettering, Berlin
I think they preferred having fast fix over having long-term sustainable solution. I haven't seen offer to provide libsystemd-notify library with minimal dependencies, which they kindly refused. They preferred bundled code over systemd bloat in comment #13. I haven't seen bloat-less library considered in the bug, but might have missed it?
The question is, how should be the separate library called. libsystem_notify? Ideas for a better name?
Compat include header to make it otherwise unmodified with libsystemd would be nice as well.
-- 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
