Zack's Kernel News
Filesystems and Cryptography
Niels de Vos pointed out that a lot of filesystems were adding support for fscrypt
, which encrypts user files, and that it might be useful for kernel users to be able to enable that kernel feature for some filesystems but not others. He proposed a simple kernel config option that would allow per-filesystem encryption. He remarked, "This RFC is mostly for checking the acceptance of this solution, or if an other direction is preferred."
Theodore Ts'o didn't like this idea at all. He remarked pointedly, "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."
Niels confirmed that the Linux distributions were a big motivator for his initial post. He said, "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."
He pointed out that the kernel actually did have special per-filesystem config options already, for ACLs and other security features. He said, "Because these exist already, I did not expect too much concerns with proposing a CONFIG_EXT4_FS_ENCRYPTION."
But Ted replied, "Actually, I was thinking of getting rid of them, as we've already gotten rid of [EXT4_FS_XATTR]." He reiterated, "there are tons of file system features that have not and/or still are not supported for distros, but for which we don't have kernel config knobs. This includes ext4's bigalloc and inline data, btrfs's dedup and reflink support, xfs online fsck, etc., etc., etc. Heck, ext4 is only supported up to a certain size by Red Hat, and we don't have a Kernel config so that the kernel will absolutely refuse to mount an ext4 file system larger than The Officially Supported RHEL Capacity Limit for Ext4."
Eric Biggers remarked, regarding Niels' proposal, "as others have pointed out, it doesn't seem worth the complexity to do this." And he went on to offer some historical background:
"Before Linux v5.1, we did have per-filesystem options for this: CONFIG_EXT4_ENCRYPTION, CONFIG_F2FS_FS_ENCRYPTION, and CONFIG_UBIFS_FS_ENCRYPTION. If you enabled one of these, it selected CONFIG_FS_ENCRYPTION to get the code in fs/crypto/. CONFIG_FS_ENCRYPTION was a tristate, so the code in fs/crypto/ could be built as a loadable module if it was only needed by filesystems that were loadable modules themselves.
"Having fs/crypto/ possibly be a loadable module was problematic, though, because it made it impossible to call into fs/crypto/ from built-in code such as fs/buffer.c, fs/ioctl.c, fs/libfs.c, fs/super.c, fs/iomap/direct-io.c, etc. So that's why we made CONFIG_FS_ENCRYPTION into a bool. At the same time, we decided to simplify the kconfig options by removing the per-filesystem options so that it worked like CONFIG_QUOTA, CONFIG_FS_DAX, CONFIG_FS_POSIX_ACL, etc."
At around this point in the conversation, Niels remarked, "What you are explaining makes sense, and I am not sure if there is another good reason why splitting out fscrypt support per filesystem would be required. I'm checking with the folks that suggested doing this, and see where we go from there." He added, "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."
And that was the end of the thread.
It's a tough balancing act! Obviously, it would be great if every feature had its own config option, as well as maybe more options to simplify having multiple features together, perhaps with exceptions specified by yet more config options. In some cases, I'm sure the kernel developers feel that a given set of features really does need such fine-grained control by system administrators, while in others they would prefer to keep the config system as simple as possible, even if it means sacrificing some behaviors system administrators might actually want.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
So Long Neofetch and Thanks for the Info
Today is a day that every Linux user who enjoys bragging about their system(s) will mourn, as Neofetch has come to an end.
-
Ubuntu 24.04 Comes with a “Flaw"
If you're thinking you might want to upgrade from your current Ubuntu release to the latest, there's something you might want to consider before doing so.
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.