On Thu, Nov 10, 2022 at 10:38:37AM -0500, Theodore Ts'o wrote: > On Thu, Nov 10, 2022 at 03:12:21PM +0100, Niels de Vos wrote: > > While more filesystems are getting support for fscrypt, it is useful to > > be able to disable fscrypt for a selection of filesystems, while > > enabling it for others. > > Could you say why you find it useful? Is it because you are concerned > about the increased binary size of a particular file system if fscrypt > is enabled? That hasn't been my experience, the hooks to call into > fscrypt are small and don't add too much to any one particular file > system; the bulk of the code is in fs/crypto. No, this isn't really a concern. I don't think the small size difference is worth the effort. > Is it because people are pushing buggy code that doesn't compile if > you enable, say, CONFIG_FS_XXX and CONFIG_FSCRYPT at the same time? It is a little of this. Not necessarily for the compiling part, more of a functional thing. And that is what comes next... > Is it because a particular distribution doesn't want to support > fscrypt with a particular file system? If so, there have been plenty > of file system features for say, ext4, xfs, and btrfs, which aren't > supported by a distro, but there isn't a CONFIG_FS_XXX_YYY to disable > that feature, nor have any distros requested such a thing --- which is > good because it would be an explosion of new CONFIG parameters. This is mostly why I sent this RFC. We are interested in enabling fscrypt for CephFS (soonish) as a network filesystem, but not for local filesystems (we recommend dm-crypt for those). The idea is that functionality that isn't available, can also not (easily) cause breakage. 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... > Or is it something else? > > Note that nearly all of the file systems will only enable fscrypt if > some file system feature flag enabls it. So I'm not sure what's the > motivation behind adding this configuration option. If memory serves, > early in the fscrypt development we did have per-file system CONFIG's > for fscrypt, but we consciously removed it, just as we no longer have > per-file system CONFIG's to enable or disable Posix ACL's or extended > attributes, in the name of simplifying the kernel config. Thanks for adding some history about this. I understand that extra options are needed while creating/tuning the filesystems. Preventing users from setting the right options in a filesystem is not easy, even if tools from a distribution do not offer setting the options. Disks can be portable, or network-attached, and have options enabled that an other distributions kernel does not (want to) support. 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. I hope this explains the intention a bit better. And as there are existing options for many filesystems to select support for xattrs, security or ACLs, I hope new options for (de)selecting filesystem encryption support is not too controversial. Thanks! Niels
