24 Jun
2024
24 Jun
'24
7:50 p.m.
On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote:
Except you now have to do the additional step of
extracting the
data from the binary logs and _then_ apply the regex filter you
were going to use in the first place, which makes the logs less
accessible. All of my systemd running machines still get rsyslog
plugged into it so it can deliver the logs to my central log host
(which then dumps them into PostgreSQL) - and to enable a quick
rummage in the local logs via less & grep.
Well, no, not necessarily. You *could* just query the structured data
directly, which avoids needing to do complex, and error-prone parsing
of the data using complex (and potentially easy to fool regex's). If
this is being done to trigger automation to handle certain exception
conditions, this could potentially be a security vulnerability if the
attacker could use /usr/ucb/logger to insert arbitrary text into the
system logs which could then potentially fool the regex parser (in the
worst case, if there things aren't properly escaped when handling the
parsed text, there might be a Bobby Tables style attack[1]).
[1] https://xkcd.com/327/
Now, you could say that there could be two separate events
notification; one which is sent via the old-fashioned text-based
syslog system, and a different one which is structured which is better
suited for large-scale automation.
So for example, at $WORK we *used* to grovel through the system logs
looking for file system corruption reports which were sent to the
console logs. But we've since added an fsnotify schema to the
upstream Linux kernel which sends a structured event notification
which isn't nearly as error-prone, and which doens't require parsing
to fetch the device name, etc. We didn't remove the old-style "print
to the console log" for backwards compatibility reasons, however, so
this didn't break people who were used to parse the console log by
hand. Linux kernel developers are a lot more about backwards
compatibility than some userspace projects (including, unfortunately,
systemd).
However, this dysfunction isn't limited to Linux userspace.
Unfortunately, in the case of (I think, but I'll Digital folks correct
me if I'm wrong) Digital's uerf and AIX's unspeakable horror ("AIX
---
it *reminds* you of Unix"), backwards compatibility wasn't considered
as important by the Product Managers who make these sorts of
decisions.
Back in the Linux-land, for a while, a number of distributions had
rsyslog installed in parallel to the systemd logging system precisely
to provide that backwards compatibility. A stable release later,
because this meant logging data was being written twice to stable
storage, rsyslog has been made no longer the default for some
distributions, but of course, you can just install rsyslog by hand if
you still want to use it.
The bottom line is that while people seem to be ranting and raving
about systemd --- and there are a lot of things that are terrible
about systemd, don't get me wrong --- I find it interesting that
legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
in the past, when in fact, the "good old days" weren't necessary all
that good --- and there *are* reasons why some engineers have
considered plain text ala the 1970's Unix philosophy to not
necessarily be the final word in systems design.
Cheers,
- Ted