Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 13 Nov 2022 22:02:37 -0800
From:   Christoph Hellwig <hch@infradead.org>
To:     Niels de Vos <ndevos@redhat.com>
Cc:     Theodore Ts'o <tytso@mit.edu>, linux-fscrypt@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Xiubo Li <xiubli@redhat.com>,
        Marcel Lauhoff <marcel.lauhoff@suse.com>
Subject: Re: [RFC 0/4] fs: provide per-filesystem options to disable fscrypt
Message-ID: <Y3HZ/To8z76vBqYo@infradead.org>
References: <20221110141225.2308856-1-ndevos@redhat.com>
 <Y20a/akbY8Wcy3qg@mit.edu>
 <Y20rDl45vSmdEo3N@ndevos-x1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y20rDl45vSmdEo3N@ndevos-x1>
Precedence: bulk

On Thu, Nov 10, 2022 at 05:47:10PM +0100, Niels de Vos wrote:
> And, there actually are options like CONFIG_EXT4_FS_POSIX_ACL and
> CONFIG_EXT4_FS_SECURITY. Because these exist already, I did not expect
> too much concerns with proposing a CONFIG_EXT4_FS_ENCRYPTION...

ext4 is a little weird there as most file systems don't do that.
So I think these should go away for ext4 as well.

> Note that even with the additional options, enabling only
> CONFIG_FS_ENCRYPTION causes all the filesystems that support fscrypt to
> have it enabled. For users there is no change, except that they now have
> an option to disable fscrypt support per filesystem.

But why would you do that anyay?