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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY autolearn=ham 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 A12D4C6379F for ; Tue, 24 Nov 2020 04:31:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4670E2085B for ; Tue, 24 Nov 2020 04:31:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726498AbgKXEbM (ORCPT ); Mon, 23 Nov 2020 23:31:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbgKXEbM (ORCPT ); Mon, 23 Nov 2020 23:31:12 -0500 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B2B9C0613CF; Mon, 23 Nov 2020 20:31:12 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 0F22D1F44A84 From: Gabriel Krisman Bertazi To: Eric Biggers Cc: Daniel Rosenberg , "Theodore Y . Ts'o" , Jaegeuk Kim , Andreas Dilger , Chao Yu , Alexander Viro , Richard Weinberger , linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, kernel-team@android.com Subject: Re: [PATCH v4 2/3] fscrypt: Have filesystems handle their d_ops Organization: Collabora References: <20201119060904.463807-1-drosen@google.com> <20201119060904.463807-3-drosen@google.com> <87y2iuj8y2.fsf@collabora.com> Date: Mon, 23 Nov 2020 23:31:05 -0500 In-Reply-To: (Eric Biggers's message of "Mon, 23 Nov 2020 14:30:35 -0800") Message-ID: <87blfnpe9i.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Eric Biggers writes: > On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote: >> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> > index 6633b20224d5..0288bedf46e1 100644 >> > --- a/fs/ext4/super.c >> > +++ b/fs/ext4/super.c >> > @@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) >> > goto failed_mount4; >> > } >> > >> > -#ifdef CONFIG_UNICODE >> > - if (sb->s_encoding) >> > - sb->s_d_op = &ext4_dentry_ops; >> > -#endif >> >> This change has the side-effect of removing the capability of the root >> directory from being case-insensitive. It is not a backward >> incompatible change because there is no way to make the root directory >> CI at the moment (it is never empty). But this restriction seems >> artificial. Is there a real reason to prevent the root inode from being >> case-insensitive? >> > > The problem is that the "lost+found" directory is special in that e2fsck needs > to be able to find it. > > That's the reason why ext4 doesn't allow the root directory to be encrypted. > (And encrypting the root directory isn't really useful anyway, since if the goal > is to encrypt a whole filesystem with one key, dm-crypt is a better solution.) > > Casefolding is a bit less problematic than encryption. But it still doesn't > entirely work, as e.g. if you name the directory "LOST+FOUND" instead (the > directory is casefolded after all...), then e2fsck can't find it. > > Unless there's a real use case for the root directory being casefolded and > people are willing to fix e2fsck, I think we should just make ext4 return an > error when setting the casefold flag on the root directory, like it does when > trying to enable encryption on the root directory. I don't have a use case where I need a root directory to be CI. In fact, when I first implemented CI, I did want to block the root directory from being made CI, just to prevent people from doing "chattr +F /" and complaining afterwards when /usr/lib breaks. My concern with the curent patch was whether this side-effect was considered, but I'm happy with either semantics. -- Gabriel Krisman Bertazi 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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, 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 7D245C64E7B for ; Tue, 24 Nov 2020 04:31:34 +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 CCFF9208B8 for ; Tue, 24 Nov 2020 04:31:33 +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="VwRq3r6r"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="aT7Fg7h6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCFF9208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.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 1khPzI-0006xx-7S; Tue, 24 Nov 2020 04:31:32 +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 1khPzF-0006xZ-8e for linux-f2fs-devel@lists.sourceforge.net; Tue, 24 Nov 2020 04:31:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To: Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VHn/LY3N41cBqb++YT7COFjZjSG3pyeFoNVSq3U3SLU=; b=VwRq3r6rSDbK2Hs3dxOHgb0/8b +eUwd7x2HLXkndLdFX8a82pI9QbVUpH3I/YarqxBaQ4aHGoD8JtsFD4j0IL8vtfr3/rtpXwvBUEx9 HvhqVwBZNGLEl1DmzS5AfgxTWzjc07MJOFchFMGg4EPvuhGS9xKdhkwbzuD/Y4lPKq9s=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject: Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VHn/LY3N41cBqb++YT7COFjZjSG3pyeFoNVSq3U3SLU=; b=aT7Fg7h6CmsYsU7IBIIR0RnSKg qh7VaTDGewLs2ifE/iYhIGhV7AOvMBcI83F2FHxO1Cm2ZEDgxhNsw9SS7WkqDYKFiQj6CIOpar5yI BMPutBeF3ETJ9TJM6SGbFDM1JBOAhdgrrHv16PsMicc6WRlynLfp2ALmNPCzCxW/6smg=; Received: from bhuna.collabora.co.uk ([46.235.227.227]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1khPzA-00Cjon-70 for linux-f2fs-devel@lists.sourceforge.net; Tue, 24 Nov 2020 04:31:29 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 0F22D1F44A84 From: Gabriel Krisman Bertazi To: Eric Biggers Organization: Collabora References: <20201119060904.463807-1-drosen@google.com> <20201119060904.463807-3-drosen@google.com> <87y2iuj8y2.fsf@collabora.com> Date: Mon, 23 Nov 2020 23:31:05 -0500 In-Reply-To: (Eric Biggers's message of "Mon, 23 Nov 2020 14:30:35 -0800") Message-ID: <87blfnpe9i.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Headers-End: 1khPzA-00Cjon-70 Subject: Re: [f2fs-dev] [PATCH v4 2/3] fscrypt: Have filesystems handle their d_ops 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: "Theodore Y . Ts'o" , Daniel Rosenberg , Richard Weinberger , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, Andreas Dilger , Alexander Viro , linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net Eric Biggers writes: > On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote: >> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> > index 6633b20224d5..0288bedf46e1 100644 >> > --- a/fs/ext4/super.c >> > +++ b/fs/ext4/super.c >> > @@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) >> > goto failed_mount4; >> > } >> > >> > -#ifdef CONFIG_UNICODE >> > - if (sb->s_encoding) >> > - sb->s_d_op = &ext4_dentry_ops; >> > -#endif >> >> This change has the side-effect of removing the capability of the root >> directory from being case-insensitive. It is not a backward >> incompatible change because there is no way to make the root directory >> CI at the moment (it is never empty). But this restriction seems >> artificial. Is there a real reason to prevent the root inode from being >> case-insensitive? >> > > The problem is that the "lost+found" directory is special in that e2fsck needs > to be able to find it. > > That's the reason why ext4 doesn't allow the root directory to be encrypted. > (And encrypting the root directory isn't really useful anyway, since if the goal > is to encrypt a whole filesystem with one key, dm-crypt is a better solution.) > > Casefolding is a bit less problematic than encryption. But it still doesn't > entirely work, as e.g. if you name the directory "LOST+FOUND" instead (the > directory is casefolded after all...), then e2fsck can't find it. > > Unless there's a real use case for the root directory being casefolded and > people are willing to fix e2fsck, I think we should just make ext4 return an > error when setting the casefold flag on the root directory, like it does when > trying to enable encryption on the root directory. I don't have a use case where I need a root directory to be CI. In fact, when I first implemented CI, I did want to block the root directory from being made CI, just to prevent people from doing "chattr +F /" and complaining afterwards when /usr/lib breaks. My concern with the curent patch was whether this side-effect was considered, but I'm happy with either semantics. -- Gabriel Krisman Bertazi _______________________________________________ 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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED 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 9C9D9C64E75 for ; Tue, 24 Nov 2020 04:33:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 AF59C20857 for ; Tue, 24 Nov 2020 04:33:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="R1lZWKig" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF59C20857 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HtgxTtqRJ5Wls5JrXOge966bl5XNrCP2do4MzwI3U7A=; b=R1lZWKig/AWPOdIGzKEi343Vj ReINIbZnfwTp4cVRJ+5tVNkLf+IJvWUSgvZkpRldBCcX4T7d45Xmd7p2Li1DBin/vrD5S9c6tv351 lscHVHu2PA/KAKmfysIFJzSSBB/q3etzRrb8iHfLmABmbFyMNWWxROBoHum7I/TIAJxuOTipzygDh yy+F00s0ow/EuYMQqypVi1Sp5PGT+DaI1aDrUXrXyHxemY7x9GYv03NkCWc3HYc5OAAbgykXO99tD 1dD4SYd5fJKyhwWWGCGj7Wk2p9YJ5qSpOuiiRhfP+DHtaXyFTC+4Oi5sUmicvmG7k9q8Y5dQJeR+o zEFZbyWHA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khPz1-0006mm-91; Tue, 24 Nov 2020 04:31:15 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khPyy-0006mJ-Ms for linux-mtd@lists.infradead.org; Tue, 24 Nov 2020 04:31:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 0F22D1F44A84 From: Gabriel Krisman Bertazi To: Eric Biggers Subject: Re: [PATCH v4 2/3] fscrypt: Have filesystems handle their d_ops Organization: Collabora References: <20201119060904.463807-1-drosen@google.com> <20201119060904.463807-3-drosen@google.com> <87y2iuj8y2.fsf@collabora.com> Date: Mon, 23 Nov 2020 23:31:05 -0500 In-Reply-To: (Eric Biggers's message of "Mon, 23 Nov 2020 14:30:35 -0800") Message-ID: <87blfnpe9i.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_233112_879608_5CC25C10 X-CRM114-Status: GOOD ( 23.63 ) 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: "Theodore Y . Ts'o" , Daniel Rosenberg , Richard Weinberger , Chao Yu , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, Andreas Dilger , Alexander Viro , linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, kernel-team@android.com 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 Eric Biggers writes: > On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote: >> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> > index 6633b20224d5..0288bedf46e1 100644 >> > --- a/fs/ext4/super.c >> > +++ b/fs/ext4/super.c >> > @@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) >> > goto failed_mount4; >> > } >> > >> > -#ifdef CONFIG_UNICODE >> > - if (sb->s_encoding) >> > - sb->s_d_op = &ext4_dentry_ops; >> > -#endif >> >> This change has the side-effect of removing the capability of the root >> directory from being case-insensitive. It is not a backward >> incompatible change because there is no way to make the root directory >> CI at the moment (it is never empty). But this restriction seems >> artificial. Is there a real reason to prevent the root inode from being >> case-insensitive? >> > > The problem is that the "lost+found" directory is special in that e2fsck needs > to be able to find it. > > That's the reason why ext4 doesn't allow the root directory to be encrypted. > (And encrypting the root directory isn't really useful anyway, since if the goal > is to encrypt a whole filesystem with one key, dm-crypt is a better solution.) > > Casefolding is a bit less problematic than encryption. But it still doesn't > entirely work, as e.g. if you name the directory "LOST+FOUND" instead (the > directory is casefolded after all...), then e2fsck can't find it. > > Unless there's a real use case for the root directory being casefolded and > people are willing to fix e2fsck, I think we should just make ext4 return an > error when setting the casefold flag on the root directory, like it does when > trying to enable encryption on the root directory. I don't have a use case where I need a root directory to be CI. In fact, when I first implemented CI, I did want to block the root directory from being made CI, just to prevent people from doing "chattr +F /" and complaining afterwards when /usr/lib breaks. My concern with the curent patch was whether this side-effect was considered, but I'm happy with either semantics. -- Gabriel Krisman Bertazi ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/