On Fri, Oct 23, 2020 at 05:51:31PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > There isn't really any valid reason to use __FSCRYPT_MODE_MAX or > FSCRYPT_POLICY_FLAGS_VALID in a userspace program. These constants are > only meant to be used by the kernel internally, and they are defined in > the UAPI header next to the mode numbers and flags only so that kernel > developers don't forget to update them when adding new modes or flags. > > In https://lkml.kernel.org/r/20201005074133.1958633-2-satyat@xxxxxxxxxx > there was an example of someone wanting to use __FSCRYPT_MODE_MAX in a > user program, and it was wrong because the program would have broken if > __FSCRYPT_MODE_MAX were ever increased. So having this definition > available is harmful. FSCRYPT_POLICY_FLAGS_VALID has the same problem. > > So, remove these definitions from the UAPI header. Replace > FSCRYPT_POLICY_FLAGS_VALID with just listing the valid flags explicitly > in the one kernel function that needs it. Move __FSCRYPT_MODE_MAX to > fscrypt_private.h, remove the double underscores (which were only > present to discourage use by userspace), and add a BUILD_BUG_ON() and > comments to (hopefully) ensure it is kept in sync. > > Keep the old name FS_POLICY_FLAGS_VALID, since it's been around for > longer and there's a greater chance that removing it would break source > compatibility with some program. Indeed, mtd-utils is using it in > an #ifdef, and removing it would introduce compiler warnings (about > FS_POLICY_FLAGS_PAD_* being redefined) into the mtd-utils build. > However, reduce its value to 0x07 so that it only includes the flags > with old names (the ones present before Linux 5.4), and try to make it > clear that it's now "frozen" and no new flags should be added to it. > > Fixes: 2336d0deb2d4 ("fscrypt: use FSCRYPT_ prefix for uapi constants") > Cc: <stable@xxxxxxxxxxxxxxx> # v5.4+ > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> Applied to fscrypt.git#master for 5.11. - Eric
