From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15374 invoked from network); 24 Feb 2021 18:38:21 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2021 18:38:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id F04509C7FA; Thu, 25 Feb 2021 04:38:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3A1619C6CE; Thu, 25 Feb 2021 04:37:58 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id BB6C69C6CE; Thu, 25 Feb 2021 04:37:54 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id B1D859BA4D for ; Thu, 25 Feb 2021 04:37:53 +1000 (AEST) Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11OIbph9025137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Feb 2021 13:37:52 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id B601D15C342C; Wed, 24 Feb 2021 13:37:51 -0500 (EST) Date: Wed, 24 Feb 2021 13:37:51 -0500 From: "Theodore Ts'o" To: Grant Taylor Message-ID: References: <78fede43-bf9b-5a56-5e59-e6ee5a0ee23d@spamtrap.tnetconsulting.net> <3d2d7b46-41e8-92d7-3a7b-d0f3006bc761@spamtrap.tnetconsulting.net> <3e41de9a-aaa3-0501-12e4-a99b589192f4@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e41de9a-aaa3-0501-12e4-a99b589192f4@spamtrap.tnetconsulting.net> Subject: Re: [TUHS] /usr separation X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Wed, Feb 24, 2021 at 10:50:03AM -0700, Grant Taylor via TUHS wrote: > > I would call this the "Tyrany of Gold", as in the reformulated Golden > > Rule, "The ones with the Gold, makes the Rules". > > Being a fan of the golden rule, I would not make, much less use, that > derivation. I think it completely changes the meaning of the spirit behind > the golden rule. Oh, sure. I agree completely that it's 180 degrees from the original golden rule; it had intended to be a joke. Unfortunately, years of living in a country whre the ones with the Gold really do make all of the Rules has gotten me to the point where if I don't laugh at it, I would have to cry.... > I seem to recall hearing about a problem where a rogue rm could accidentally > wipe out part of the UEFI. Maybe it was the contents of the /boot/efi > partition. So, I'd suggest a happy medium of mounting it Read-Only. That > way it's known to be used /and/ it's protected from a simple rogue rm. It > can relatively easily be re-mounted as Read-Write when necessary. As well > as subsequently re-mounted back to Read-Only. So technically it doesn't wipe out UEFI; it just will destroy the ability to boot the system. (e.g., this is where Grub lives, and if you delete it, UEFI will no longer be able to launch Grub, and hence, not boot Linux.) Fortunately, if you have a rescue CD / USB Thumb drive, it's relatively easy to recover from this. A rogue rm which deletes /bin (even if /bin is a symlink to /usr/bin, all of the shell scripts and /etc/passwd entries probably still refer to /bin/sh) is going to make the system similarly unbootable. As far as making a system more robust against rogue rm's, I really like scheme used by ChromeOS, where the entire file system is not only read-only, but protected by a cryptographic Merkle Tree such that if malware attempts to modify it, the system will crash. This is combined with firmware which will only load a kernel with a valid digital signature, and the user data is stored on an encrypted file system mounted on /mnt/stateful_partition and it is the only file system mounted read/write on a ChromeOS system. It violates a lot of expectations about where files should live on a "normal" Unix or Linux system, but it's defnitely way more safe and secure. > I feel like we've already abandoned i386 as in 80386 (or compatible) > architecture. I think we now require Pentium (586?) or better. At some > point, we'll completely remove 32-bit support from mainstream Linux > distributions, thus requiring something from the 21st century. For now, as far as I know, Debian still supports a 486 (or i386 with an i387 co-processor, which was my first Linux system). But yes, it is very likely, absent people showing up to volunteer to support 32-bit userspace at Debian (e.g., ongoing security updates, support for the i386 build farm, reporting and triaging build failures of packages on i386, etc.), that the i386 arch will probably get dropped after Debian Bullseye release (which will probably happpen sometime in mid-2021 if I had to guess). I'm not sure there are any 486's around any more, and it's likely most uses of systems with i386 binaries are on 64-bit processors running in 32-bit mode, so 486 vs 586 is probably not all that important in the grand scheme of things. - Ted