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 X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30352C48BD6 for ; Wed, 26 Jun 2019 02:34:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A0EF2085A for ; Wed, 26 Jun 2019 02:34:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="G/aYnUXE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726822AbfFZCeY (ORCPT ); Tue, 25 Jun 2019 22:34:24 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:53852 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbfFZCeW (ORCPT ); Tue, 25 Jun 2019 22:34:22 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2TYh8026692; Wed, 26 Jun 2019 02:33:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=fawPQY/UISfSH6DvrztcWabWXm47TtXieQJWSELxOKQ=; b=G/aYnUXEphMoz0tS57JlzzJidDTnCP3JwQDBotgjzdUejbyDPYJP0ww7UIoJ9qziXtze V8WfKNQm07ANAuCm8B36a/SSrlnF4iTQcfj6+NLwHRqJVTP47OZew3gQAlm23ALl0Umk xq3Im7dO6UOb8iISWt8zfUFMNhrviliNGlkVCg5a0cfeb27h0Drq5G4rl1p6MZONDA9T LOJ0700Z6AtHwS+rK56pnb/hADrt/VxtC4zKanyLYIE10jvKJ1zJCdEbZq2d2Ps/KjeI pOTljCBSvtHNdPtMRfVj73W2qgv94B8p+0UE9rS1oOhD12Oac8PGEIcskWt9iHiUUTuy 2A== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2t9c9pqjk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:08 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2Wj2o020612; Wed, 26 Jun 2019 02:33:07 GMT Received: from pps.reinject (localhost [127.0.0.1]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 02:33:07 +0000 Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x5Q2X7If021156; Wed, 26 Jun 2019 02:33:07 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2ec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:07 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x5Q2X6O7021146; Wed, 26 Jun 2019 02:33:06 GMT Received: from localhost (/10.159.230.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2019 19:32:55 -0700 USER-AGENT: StGit/0.17.1-dirty MIME-Version: 1.0 Message-ID: <156151637248.2283603.8458727861336380714.stgit@magnolia> Date: Tue, 25 Jun 2019 19:32:52 -0700 (PDT) From: "Darrick J. Wong" To: matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, darrick.wong@oracle.com, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, viro@zeniv.linux.org.uk, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, jk@ozlabs.org Cc: reiserfs-devel@vger.kernel.org, linux-efi@vger.kernel.org, devel@lists.orangefs.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: [PATCH v5 0/5] vfs: make immutable files actually immutable Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9299 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260027 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hi all, The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This has been lightly tested with fstests. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=immutable-files fstests git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=immutable-files From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darrick J. Wong Date: Tue, 25 Jun 2019 19:32:52 -0700 (PDT) Subject: [Ocfs2-devel] [PATCH v5 0/5] vfs: make immutable files actually immutable Message-ID: <156151637248.2283603.8458727861336380714.stgit@magnolia> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, darrick.wong@oracle.com, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, viro@zeniv.linux.org.uk, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, jk@ozlabs.org Cc: reiserfs-devel@vger.kernel.org, linux-efi@vger.kernel.org, devel@lists.orangefs.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org Hi all, The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This has been lightly tested with fstests. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=immutable-files fstests git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=immutable-files 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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 898DCC48BD5 for ; Wed, 26 Jun 2019 02:34:15 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5DCF82085A; Wed, 26 Jun 2019 02:34:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="j2cjkxoF"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="fekzI9pt"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="G/aYnUXE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DCF82085A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hfxl5-00027p-Jp; Wed, 26 Jun 2019 02:34:03 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hfxl3-00027Y-VA for linux-f2fs-devel@lists.sourceforge.net; Wed, 26 Jun 2019 02:34:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:Subject:Cc: To:From:Date:Message-ID:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fawPQY/UISfSH6DvrztcWabWXm47TtXieQJWSELxOKQ=; b=j2cjkxoFAOL8SNR/WC+V/aIybm 5VltKr89MjNZ1T8pSssQCQoJzV0Gfh5H5bK3/iy2zlghFqtn/VWUJxs8ptpedR3u2Ufs4z+m5h2Hx mc6pn3neWDYzLKtJwcbAMHtJmdGhL2Wk666yB8cp9dNhvK/2bJpyBsfcRoKuD2BT8AUk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:Subject:Cc:To:From:Date:Message-ID :MIME-Version:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=fawPQY/UISfSH6DvrztcWabWXm47TtXieQJWSELxOKQ=; b=f ekzI9ptIOhdFSjNviuEKvDLL/yO/nhkUYhLysyfmjOZbmc8LTdLtl/cvWzS6G0n3A7B4i68vhIhtJ 85K/+hiRhS7Qb19g8VLhxh6UuXCA+JcQzpSN9BcssgQAkszceVtDH0vYgdtTBU/ZKOBgHyu41mNFi tgNqB5EUaDB0ueDc=; Received: from aserp2120.oracle.com ([141.146.126.78]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1hfxlD-00EEF7-Aa for linux-f2fs-devel@lists.sourceforge.net; Wed, 26 Jun 2019 02:34:13 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2TYh8026692; Wed, 26 Jun 2019 02:33:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=fawPQY/UISfSH6DvrztcWabWXm47TtXieQJWSELxOKQ=; b=G/aYnUXEphMoz0tS57JlzzJidDTnCP3JwQDBotgjzdUejbyDPYJP0ww7UIoJ9qziXtze V8WfKNQm07ANAuCm8B36a/SSrlnF4iTQcfj6+NLwHRqJVTP47OZew3gQAlm23ALl0Umk xq3Im7dO6UOb8iISWt8zfUFMNhrviliNGlkVCg5a0cfeb27h0Drq5G4rl1p6MZONDA9T LOJ0700Z6AtHwS+rK56pnb/hADrt/VxtC4zKanyLYIE10jvKJ1zJCdEbZq2d2Ps/KjeI pOTljCBSvtHNdPtMRfVj73W2qgv94B8p+0UE9rS1oOhD12Oac8PGEIcskWt9iHiUUTuy 2A== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2t9c9pqjk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:08 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2Wj2o020612; Wed, 26 Jun 2019 02:33:07 GMT Received: from pps.reinject (localhost [127.0.0.1]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 02:33:07 +0000 Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x5Q2X7If021156; Wed, 26 Jun 2019 02:33:07 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2ec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:07 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x5Q2X6O7021146; Wed, 26 Jun 2019 02:33:06 GMT Received: from localhost (/10.159.230.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2019 19:32:55 -0700 USER-AGENT: StGit/0.17.1-dirty MIME-Version: 1.0 Message-ID: <156151637248.2283603.8458727861336380714.stgit@magnolia> Date: Tue, 25 Jun 2019 19:32:52 -0700 (PDT) From: "Darrick J. Wong" To: matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, darrick.wong@oracle.com, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, viro@zeniv.linux.org.uk, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, jk@ozlabs.org X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9299 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260027 X-Headers-End: 1hfxlD-00EEF7-Aa Subject: [f2fs-dev] [PATCH v5 0/5] vfs: make immutable files actually immutable X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-efi@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, devel@lists.orangefs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net Hi all, The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This has been lightly tested with fstests. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=immutable-files fstests git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=immutable-files _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9333C48BD5 for ; Wed, 26 Jun 2019 02:35:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9582A20645 for ; Wed, 26 Jun 2019 02:35:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MvoGSbT2"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="G/aYnUXE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9582A20645 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:To:From:Date:Message-ID: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=q+5puTvRmphf/EiI6P9zwBGJjRDuQ7E+0utxllsaj4A=; b=MvoGSbT2SFEFyg YK6RwNzRI96qxBAoZqRTb+8qmHmdpiwVqfJPh7FLzwTOoASzDFLHOr/1gy08zXpXjF7fvPhz4a63W nyjkEezk505pgV4SS6t9e6D1wmHK0MM+5aBtRiLZVKQhvPvFAqw9l1gSrXo3XMx+ayaBhWZntpoMk 8MBWMHdIZR1ZVvPEAf/23je3aNum6s6Z/nnB5sEDUaHG5QmpXZEQ3SKwz9gGXmz3upJ6NeXnfuNbR nCKd7rJtiNYTE9McRrsgH19WVtAAAvZuUVMe9L4Osksp4Hh8Eq04c5HcNhzg12W9TtUc9jT+iw4Lr HTIroVaNi4Meb3bWOHeg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hfxm3-0004jc-QR; Wed, 26 Jun 2019 02:35:04 +0000 Received: from aserp2120.oracle.com ([141.146.126.78]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hfxkQ-00036u-OL for linux-mtd@lists.infradead.org; Wed, 26 Jun 2019 02:33:24 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2TYh8026692; Wed, 26 Jun 2019 02:33:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=fawPQY/UISfSH6DvrztcWabWXm47TtXieQJWSELxOKQ=; b=G/aYnUXEphMoz0tS57JlzzJidDTnCP3JwQDBotgjzdUejbyDPYJP0ww7UIoJ9qziXtze V8WfKNQm07ANAuCm8B36a/SSrlnF4iTQcfj6+NLwHRqJVTP47OZew3gQAlm23ALl0Umk xq3Im7dO6UOb8iISWt8zfUFMNhrviliNGlkVCg5a0cfeb27h0Drq5G4rl1p6MZONDA9T LOJ0700Z6AtHwS+rK56pnb/hADrt/VxtC4zKanyLYIE10jvKJ1zJCdEbZq2d2Ps/KjeI pOTljCBSvtHNdPtMRfVj73W2qgv94B8p+0UE9rS1oOhD12Oac8PGEIcskWt9iHiUUTuy 2A== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2t9c9pqjk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:08 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5Q2Wj2o020612; Wed, 26 Jun 2019 02:33:07 GMT Received: from pps.reinject (localhost [127.0.0.1]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 02:33:07 +0000 Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x5Q2X7If021156; Wed, 26 Jun 2019 02:33:07 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2t9p6uh2ec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 02:33:07 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x5Q2X6O7021146; Wed, 26 Jun 2019 02:33:06 GMT Received: from localhost (/10.159.230.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2019 19:32:55 -0700 USER-AGENT: StGit/0.17.1-dirty MIME-Version: 1.0 Message-ID: <156151637248.2283603.8458727861336380714.stgit@magnolia> Date: Tue, 25 Jun 2019 19:32:52 -0700 (PDT) From: "Darrick J. Wong" To: matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, darrick.wong@oracle.com, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, viro@zeniv.linux.org.uk, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, jk@ozlabs.org Subject: [PATCH v5 0/5] vfs: make immutable files actually immutable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9299 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260027 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190625_193322_908220_72B33585 X-CRM114-Status: GOOD ( 11.57 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-efi@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, devel@lists.orangefs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org Hi all, The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This has been lightly tested with fstests. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=immutable-files fstests git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=immutable-files ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Darrick J. Wong" Subject: [PATCH v5 0/5] vfs: make immutable files actually immutable Date: Tue, 25 Jun 2019 19:32:52 -0700 (PDT) Message-ID: <156151637248.2283603.8458727861336380714.stgit@magnolia> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : list-id : list-unsubscribe : list-archive : list-post : list-help : list-subscribe : content-type : content-transfer-encoding : sender; s=corp-2018-07-02; bh=v9lHOQqdxa+gAds53trZvNGGeCq3LsiSw99vIS/icPw=; b=LzJBkMIAuX6vqAPgk7/l+NRkCE3poPzLbLXqYNdR0Fi19v7QeHR3UdFPNMPaS6W1a51D G/bvTfDOSAR4inCj/Gn9qF7ilMGg4mcqyi+ufdFK/LXcvlEQ1oD1xaxC4QDLaFd3dkaQ ugHSYg7szRNV14qcl1wK68GJSDj9RS/GPaF1CUdxFRXRjiJfkmnV/fZeeqHgbtJnv414 50iiy9/Lw1LgSJo39m9/J7yB1x6GNiRJf0AHTJs4QWQcPml+egOfHQJFONn7Q9xZBDLh BHierr+hzosgp/u7ycolKv0tmQ80p7j6xGRa2D5g1dovUv4be7w039D3TM6vbt1otY33 yg== List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com To: matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, darrick.wong@oracle.com, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, viro@zeniv.linux.org.uk, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, jk@ozlabs.org Cc: linux-efi@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, devel@lists.orangefs.org Hi all, The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This has been lightly tested with fstests. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=immutable-files fstests git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=immutable-files