-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-18 20:21, Greg Freemyer wrote:
I'd like to know more about this. In particular from a authenticity and integrity perspective.
Comments about those, or pointers to discussion about same would be appreciated.
==== Here is Lennart Poettering's list of problems with what journald replaces:
1) The message data is generally not authenticated, every local process can claim to be Apache under PID 4711, and syslog will believe that and store it on disk.
I'm not aware that this has changed with journal. I can use "logger" in a script to send entries to syslog and journald, and they are more or less free form.
2) The data logged is very free-form. Automated log-analyzers need to parse human language strings to a) identify message types, and b) parse parameters from them. This results in regex horrors, and a steady need to play catch-up with upstream developers who might tweak the human language log strings in new versions of their software. Effectively, in a away, in order not to break user-applied regular expressions all log messages become ABI of the software generating them, which is usually not intended by the developer.
I don't see this as changed. The application or system programmer chooses what to send to the log and in which format.
3) The timestamps generally do not carry timezone information, even though some newer specifications define support for it.
I understand the timestamp is a binary, and the syslog application formats it as the administrator defines. There is, I understand, one timestamp as sent by the application, and another as stamped by the syslog daemon.
4) Syslog is only one of many log systems on local machines. Separate logs are kept for utmp/wtmp, lastlog, audit, kernel logs, firmware logs, and a multitude of application-specific log formats. This is not only unnecessarily complex, but also hides the relation between the log entries in the various subsystems.
It is up to the programmers to use syslog or not. This is not one ring to rule them all.
5) Reading log files is simple but very inefficient. Many key log operations have a complexity of O(n). Indexing is generally not available.
6) The syslog network protocol is very simple, but also very limited. Since it generally supports only a push transfer model, and does not employ store-and-forward, problems such as Thundering Herd or packet loss severely hamper its use.
7) Log files are easily manipulable by attackers, providing easy ways to hide attack information from the administrator
Yes. But. With some syslog daemons you can choose to save into a database instead than as text.
8) Access control is non-existent. Unless manually scripted by the administrator a user either gets full access to the log files, or no access at all.
Partly. The administrator may give access to one log file or others, as he wishes, with standard *nix type file permissions and acls.
9) The meta data stored for log entries is limited, and lacking key bits of information, such as service name, audit session or monotonic timestamps.
10) Automatic rotation of log files is available, but less than ideal in most implementations: instead of watching disk usage continuously to enforce disk usage limits rotation is only attempted in fixed time intervals, thus leaving the door open to many DoS attacks.
On the other hand, I have seen journald to grow excessively, like gigabytes in days, because one particular service logs a lot. Say a busy mail server or a busy news server. There is no provision with journald to purge selectively a class of logs that is not wanted to be kept for long. Also, accessing the journal can be very slow unless the machine has an SSD. An order of magnitude slower than traditional syslog.
11) Rate limiting is available in some implementations, however, generally does not take the disk usage or service assignment into account, which is highly advisable.
12) Compression in the log structure on disk is generally available but usually only as effect of rotation and has a negative effect on the already bad complexity behaviour of many key log operations.
Perhaps not if syslog is writing to a database. It is then up to the database engine.
13) Classic Syslog traditionally is not useful to handle early boot or late shutdown logging, even though recent improvements (for example in systemd) made this work.
No, early boot could be logged to syslog. When the syslog service started, the kernel log entries could be logged to syslog, to another log file, or both. The openSUSE implementation was to another file, and as far as I remember, everything was included. As to halt messages, nothing after the syslog daemon closes can be stored, obviously. Same with journal. Does it stop later? I don't know, but at some point it has to stop.
14) Binary data cannot be logged, which in some cases is essential (Examples: ATA SMART blobs or SCSI sense data, firmware dumps)
Better into separate files, IMHO. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhYCCoACgkQja8UbcUWM1w7FQD+LPoYzX3UdJs+nqP4hQze1mLb FaMKJ5/KuNyrASyLvS0A/0ijYgF8wlUoL/j7tbIvE5JL/uBiJWX+2OkKNcMRhAXa =kci2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org