From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id D1E4222AFC for ; Mon, 24 Jun 2024 15:51:29 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 709BA431E1; Mon, 24 Jun 2024 23:51:23 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id A7643431DD for ; Mon, 24 Jun 2024 23:51:12 +1000 (AEST) Received: from cwcc.thunk.org (pool-108-26-156-193.bstnma.fios.verizon.net [108.26.156.193]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 45ODonDc006139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2024 09:50:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1719237066; bh=bXjsvk6Q+0c6PRhgVXdRHUVJobDRk4CCBtyBDD1sM+k=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=nBNSEhgAowMTCIp9luCs6SFewrHGdmAhVWqnXAnIPP1LW3c/9a8MK1dC3W4PD4pjs e2EP+WqumiOPDoxJvBNt2Jk0POlSu8KmAY9KlRNquTHIhlyEkod56uzZPR8CpC52LA OxCQWx1KLGxbEuql6EufsLocHbJghI2gpuQfxcQ10n7fIgykypvsk7EpgaBWONIHkc MS7on+2BXaFv8blFXKmI1kYLgbvmH6/QoHMgXFvhD9SWIUzjUosZLN6M7IbBb/niQt y4hVCALBLILNCbz0Hu/FxREEVl6b1fMAcS93vlqZT2DBAUqQCQ6HlDWRvktvL9jOk+ cfJi8P82FFOFg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 2182515C00DC; Mon, 24 Jun 2024 09:50:49 -0400 (EDT) Date: Mon, 24 Jun 2024 09:50:49 -0400 From: "Theodore Ts'o" To: Alexander Schreiber Message-ID: <20240624135049.GA280025@mit.edu> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <22508b22-db5f-491e-bc02-2d4ab4d33cd9@home.arpa> <87o77s77lj.fsf@gmail.com> <20240623190002.GB7185@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: P2XJ5MLBJ5RLW4N2RTQ25SQYDJE622JU X-Message-ID-Hash: P2XJ5MLBJ5RLW4N2RTQ25SQYDJE622JU X-MailFrom: tytso@mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Alexis , The Unix Heritage Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Version 256 of =?utf-8?q?systemd_boasts_=2742=25_less_Unix_philosophy=27_=E2=80=A2?= The Register List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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