More relevant, it caps `log_ident` to a very short length. If my math is correct, the max length of the first snprintf is 72 bytes (actually less with real-world valid PIDs), and the buffer is 1024.
As usual, MUSL is secure at the cost of giving up usefulness. A 32-byte buffer might seem like a lot, but there are dozens of programs with a name longer than 31 bytes on my system. `dbus-update-activation-environment` is the most interesting (most others are gcc/binutils), and I know dbus in general uses syslog, though I haven't traced this particular entry point.
Yeah. You have to math out the various fields but I agree it appears to end up a few orders of magnitude smaller than 1024. It's just not particularly explicit.
> As usual, MUSL is secure at the cost of giving up usefulness.
I would say 'Musl is deliberately simple at the cost of usefulness'. The simplicity lends itself to correctness and security.
Btw, since Musl does not implicitly construct log_ident from argv[0], program name is sort of irrelevant unless that program explicitly openlog()s with argv[0]. dbus-update-activation-environment does not appear to openlog or use syslog at all: https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/tools... Instead it prints error messages to stderr.
As usual, MUSL is secure at the cost of giving up usefulness. A 32-byte buffer might seem like a lot, but there are dozens of programs with a name longer than 31 bytes on my system. `dbus-update-activation-environment` is the most interesting (most others are gcc/binutils), and I know dbus in general uses syslog, though I haven't traced this particular entry point.