On Di, 02.04.24 14:04, Petr Menšík (pemensik(a)redhat.com) 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
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.
sshd upstream understood this btw:
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
Lennart
--
Lennart Poettering, Berlin