From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9C43F139694 for ; Thu, 13 Jul 2017 15:06:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73FC3E0C75; Thu, 13 Jul 2017 15:06:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 22656E0BE2 for ; Thu, 13 Jul 2017 15:06:50 +0000 (UTC) Received: from localhost (unknown [91.246.102.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id F17F83419D6 for ; Thu, 13 Jul 2017 15:06:48 +0000 (UTC) Date: Thu, 13 Jul 2017 18:06:44 +0300 From: Andrew Savchenko To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only Message-Id: <20170713180644.64eabb8041e9438f190889c0@gentoo.org> In-Reply-To: <20170713175829.f48cc15270dbc1bdf1907341@gentoo.org> References: <20170712154236.GA10286@whubbs1.gaikai.biz> <20170712214408.GA13328@whubbs1.gaikai.biz> <20170713093021.2b0bcf21b6ebb6921245fbe0@gentoo.org> <32458e65-d66d-fcdc-5b0a-97d3c480d14a@iee.org> <20170713175829.f48cc15270dbc1bdf1907341@gentoo.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.30; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Thu__13_Jul_2017_18_06_44_+0300_.c6W0=G91W3Hdevr" X-Archives-Salt: bafd5da6-eaf1-4bab-ab11-d4a8a116190f X-Archives-Hash: 87e7964a616ecf24f9ec0a4927f53ed9 --Signature=_Thu__13_Jul_2017_18_06_44_+0300_.c6W0=G91W3Hdevr Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 13 Jul 2017 17:58:29 +0300 Andrew Savchenko wrote: > On Thu, 13 Jul 2017 10:29:06 -0400 Mike Gilbert wrote: > > On Thu, Jul 13, 2017 at 7:35 AM, M. J. Everitt wr= ote: > > > On 13/07/17 12:09, Rich Freeman wrote: > > >> Presumably you'd only want to remount it if it was mounted ro to > > >> start, since it sounds like openrc will be diverging from systemd > > >> behavior here. > > >> > > >> While it seems like a good idea I'm not sure how big an improvement = it > > >> is in the larger scheme. We're worried about root accidentially > > >> modifying efivars, but we have no safeguards against root writing to > > >> /dev/sda, and the latter seems much more likely to cause harm, and is > > >> harder to fix. > > >> > > > In case you weren't aware, Rich, rewriting the efivars actually writes > > > to the system BIOS, which renders the computer completely unbootable = .. > > > not quite the same as erasing the boot sector of your hard disk, where > > > you simply plug in another device, and Off you go ... > > > > >=20 > > We are actually talking about protecting people who run something like > > rm -rf /sys/firmware/efi/efivars/ as root. > > > > If you are dumb enough to do something like that, you almost deserve > > to spend a couple hundred on a new motherboard. > =20 > Or just rm -rf / > [pedantic] > of course with newer rm versions one needs to run: > rm -rf --no-preserve-root / > or > rm -rf /* /.* > [/pedantic] >=20 > But in some scenarios this command is normal. E.g. user installs > Gentoo from some live dvd/flash, makes some mistakes, understands > that system is broken beyond repair and decides to start over again. > If there is no need to recreate filesystem itself or partition > layout, running rm -rf / as above is quite reasonable. >=20 > When running this command user expects to kill the data, but not > the hardware. That is my point. I can't call such action dumb. One more example: remember the bumblebee install script bug[1]: due to a typo the whole /usr was removed, the same may happen with /sys one day. If simple file removal results in dead hardware this is no go. [1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 Best regards, Andrew Savchenko --Signature=_Thu__13_Jul_2017_18_06_44_+0300_.c6W0=G91W3Hdevr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAllnjIQACgkQ9lNaM7oe 5I2miw//TF6e+JC3DCstBPbN6S9W6nZzGol7qmtxkt7xeb6s8BN7pTMv6Xkd8H9e fEKqjKxJHN1WSnePFp6sLJYSgPysXHhGWwgAV08ihOuRNPPNf5X4jxMeRVB59jCb KkArNAbgWY8zlbHRgseWTwWEmJn4BvOXC38wGX5ShnCsTG8hcDB0inweEuSqVUga vIcLgp9BCh0XYt7HuUOD7l2fw0rClctMbWEbmT6A8Q3gbksZwKRSJwr85jKxcYSQ c8vj39nZU22BtD5DPn0uW608Z3ZC0s7VwW+dK/9bam0NJy54ezZNe0YMl5OqBS3D 30SCtIRiJ8UEDnnYIcBL2W2eIoIVwaeIOhgWTxrYkXm1FdwfnZV/fFfus0G/z4F5 fhVREcI2+HDw3ckn3URrKBzIa1mGw9VfMYtJoT/5mJpjpX+S4yH42MQPHsMGDuR2 1s4fF7qT3UgneuHZaxD+ENzMcMhO+0um16kFIfFl30QHPLG/y94QnVGHwhz2z4lb cQRm/2Ry1uacSBq3Hdr2wJwJPeEG8uJD5NrUwPEdXFAlVkzk75/oCm0AWaM9GWcc xBgrw0ceQOOgOh2XqngNEGNOL0ezaB0qEWxWLgDIC8u9dJVIWIbYae+T2DWWxaRC Db+SpivIw1ULvjCPDk5j9Idk8rANMWZQh6wNU+pLHqUemLe/mkM= =he4M -----END PGP SIGNATURE----- --Signature=_Thu__13_Jul_2017_18_06_44_+0300_.c6W0=G91W3Hdevr--