linux-kernel - Re: [RFC 0/4] fs: provide per-filesystem options to disable fscrypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y3eFFrhT3b0yoti9@ndevos-x1>
Date:   Fri, 18 Nov 2022 14:13:58 +0100
From:   Niels de Vos <ndevos@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Theodore Ts'o <tytso@....edu>, linux-fscrypt@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xiubo Li <xiubli@...hat.com>,
        Marcel Lauhoff <marcel.lauhoff@...e.com>
Subject: Re: [RFC 0/4] fs: provide per-filesystem options to disable fscrypt

On Sun, Nov 13, 2022 at 10:02:37PM -0800, Christoph Hellwig wrote:
> 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.

Yeah, I understand that there is a preference for reducing the number of
Kconfig options for filesystems. That indeed would make it a little
easier for users, so I am supportive of that 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?

An other mail in this thread contains a description about that. It is
more about being able to provide a kernel build that is fully tested,
and enabling more options (or being unable to disable features)
increases the testing efforts that are needed.

However, as Ted pointed out, there are other features that can not be
disabled or limited per filesystem, so there will always be a gap in
what can practically be tested.

Thanks,
Niels