From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A24C9EB64D9 for ; Wed, 14 Jun 2023 10:37:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235309AbjFNKhC (ORCPT ); Wed, 14 Jun 2023 06:37:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235120AbjFNKg5 (ORCPT ); Wed, 14 Jun 2023 06:36:57 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E3C2B5; Wed, 14 Jun 2023 03:36:56 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id EB09322493; Wed, 14 Jun 2023 10:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1686739014; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sFuunLuk/KGPgOZE70zqAYLnO7a/eDeyuBJEDejMyac=; b=RAyFpTYpW6tCEvx75rYKbFCiIUGWbm2HXHnx5MhUkbHEkfb5MkArgvn1tnoWFQuKMstQ2I PBSMWyyIyShG9i//UBHQMZDt6emgx+2ksCO97cwEKt4p1dpg4bnGV/3NagbYMtkLs3zThg HwNd3KbsTgYBHZ0X471sCm7frRqm6WM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1686739014; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sFuunLuk/KGPgOZE70zqAYLnO7a/eDeyuBJEDejMyac=; b=zqYS6atnPsqDHm9nC/oXo7/uQvjlA5j6TWQLxZPps1LAstmr2Ck8XzzguQXfkQ1CFJQBLB Ju5UxDbVwdsoW9BQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id DCCA01357F; Wed, 14 Jun 2023 10:36:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id d0vdNUaYiWTCfQAAMHmgww (envelope-from ); Wed, 14 Jun 2023 10:36:54 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 727D1A0755; Wed, 14 Jun 2023 12:36:54 +0200 (CEST) Date: Wed, 14 Jun 2023 12:36:54 +0200 From: Jan Kara To: Christian Brauner Cc: Christoph Hellwig , Dmitry Vyukov , Jan Kara , Jens Axboe , linux-block@vger.kernel.org, Ted Tso , yebin , linux-fsdevel@vger.kernel.org, syzkaller Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices Message-ID: <20230614103654.ydiosiv6ptljwd7i@quack3> References: <20230612161614.10302-1-jack@suse.cz> <20230614-anstalt-gepfercht-affd490e6544@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230614-anstalt-gepfercht-affd490e6544@brauner> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed 14-06-23 10:18:16, Christian Brauner wrote: > On Wed, Jun 14, 2023 at 12:17:26AM -0700, Christoph Hellwig wrote: > > On Tue, Jun 13, 2023 at 08:09:14AM +0200, Dmitry Vyukov wrote: > > > I don't question there are use cases for the flag, but there are use > > > cases for the config as well. > > > > > > Some distros may want a guarantee that this does not happen as it > > > compromises lockdown and kernel integrity (on par with unsigned module > > > loading). > > > For fuzzing systems it also may be hard to ensure fine-grained > > > argument constraints, it's much easier and more reliable to prohibit > > > it on config level. > > > > I'm fine with a config option enforcing write blocking for any > > BLK_OPEN_EXCL open. Maybe the way to it is to: > > > > a) have an option to prevent any writes to exclusive openers, including > > a run-time version to enable it > > I really would wish we don't make this runtime configurable. Build time > and boot time yes but toggling it at runtime makes this already a lot > less interesting. I see your point from security POV. But if you are say a desktop (or even server) user you may need to say resize your LVM or add partition to your disk or install grub2 into boot sector of your partition. In all these cases you need write access to a block device that is exclusively claimed by someone else. Do you mandate reboot in permissive mode for all these cases? Realistically that means such users just won't bother with the feature and leave it disabled all the time. I'm OK with such outcome but I wanted to point out this "no protection change after boot" policy noticably restricts number of systems where this is applicable. Honza -- Jan Kara SUSE Labs, CR