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 53AE5139694 for ; Thu, 13 Jul 2017 16:47:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 816B2E0E7B; Thu, 13 Jul 2017 16:47:24 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 245F0E0E2C for ; Thu, 13 Jul 2017 16:47:24 +0000 (UTC) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 0E9593418BB for ; Thu, 13 Jul 2017 16:47:23 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id v202so44551622itb.0 for ; Thu, 13 Jul 2017 09:47:23 -0700 (PDT) X-Gm-Message-State: AIVw1108qmGVBhV5HWAqNKSCMb4VF5yAWeAupN685K7z1AqjwaAfN770 2CeNNFOK7X2coLeWBMuqtbtTwFH3nQ== X-Received: by 10.107.53.25 with SMTP id c25mr4138240ioa.123.1499964441149; Thu, 13 Jul 2017 09:47:21 -0700 (PDT) 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 Received: by 10.107.175.210 with HTTP; Thu, 13 Jul 2017 09:47:00 -0700 (PDT) In-Reply-To: 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> From: Mike Gilbert Date: Thu, 13 Jul 2017 12:47:00 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only To: Gentoo Dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 763f1b50-1b2b-4fc5-8ee8-2d2b9105b99e X-Archives-Hash: decbfce7aca6fb32a08612520171fcaf On Thu, Jul 13, 2017 at 12:45 PM, Mike Gilbert wrote: > On Thu, Jul 13, 2017 at 10:58 AM, 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 wrote: >>> > 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 ... >>> > >>> >>> 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. >> >> Or just rm -rf / >> [pedantic] >> of course with newer rm versions one needs to run: >> rm -rf --no-preserve-root / >> or >> rm -rf /* /.* >> [/pedantic] >> >> 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. >> >> 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. >> >> Best regards, >> Andrew Savchenko > > Point taken. > > Although, if the user is in the process of installing Gentoo, efivarfs > is likely to be mounted rw anyway so that the user can install a boot > loader. Having grub-install perform the remount would minimize this > small risk I suppose. s/grub-install/efibootmgr/; grub-install does not update efivarfs directly, but rather calls efibootmgr to do it.