From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:36736 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726041AbeLHAts (ORCPT ); Fri, 7 Dec 2018 19:49:48 -0500 Date: Sat, 8 Dec 2018 00:49:44 +0000 From: Al Viro To: Alexander Lochmann Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kara , Horst Schirmeier Subject: Re: [PATCH] Fix sync. in blkdev_write_iter() acessing i_flags Message-ID: <20181208004944.GA2217@ZenIV.linux.org.uk> References: <4903939e-d3d6-b0c2-9c33-0fea0a61213c@tu-dortmund.de> <20181207175811.GZ2217@ZenIV.linux.org.uk> <5c86e85f-0ad4-935a-3021-7046551f361f@tu-dortmund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c86e85f-0ad4-935a-3021-7046551f361f@tu-dortmund.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Dec 07, 2018 at 08:49:16PM +0100, Alexander Lochmann wrote: > > _What_ SUID bit? We are talking about a write to block device, for fsck sake... > > > That's the way I understood Jan's explanation: > " > Thinking more about this I'm not sure if this is actually the right > solution. Because for example the write(2) can set S_NOSEC flag wrongly > when it would race with chmod adding SUID bit. So probably we rather need > to acquire i_rwsem in blkdev_write_iter() if file does not have S_NOSEC set > (we don't want to acquire it unconditionally as that would heavily impact > scalability of block device writes). IDGI. We are talking about a block device here. What business could file_remove_privs() have doing _anything_ to it? should_remove_suid() returns to return 0 for those; what case do you have in mind? Somebody setting security.capabilities on a block device inode? IMO the bug here is file_remove_privs() not buggering off immediately after having observed that we are dealing with a block device. It really has nothing useful to do.