On Sun, Jan 19, 2020 at 10:07:32PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> When an encryption key can't be fully removed due to file(s) protected
> by it still being in-use, we shouldn't really print the path to one of
> these files to the kernel log, since parts of this path are likely to be
> encrypted on-disk, and (depending on how the system is set up) the
> confidentiality of this path might be lost by printing it to the log.
>
> This is a trade-off: a single file path often doesn't matter at all,
> especially if it's a directory; the kernel log might still be protected
> in some way; and I had originally hoped that any "inode(s) still busy"
> bugs (which are security weaknesses in their own right) would be quickly
> fixed and that to do so it would be super helpful to always know the
> file path and not have to run 'find dir -inum $inum' after the fact.
>
> But in practice, these bugs can be hard to fix (e.g. due to asynchronous
> process killing that is difficult to eliminate, for performance
> reasons), and also not tied to specific files, so knowing a file path
> doesn't necessarily help.
>
> So to be safe, for now let's just show the inode number, not the path.
> If someone really wants to know a path they can use 'find -inum'.
>
> Fixes: b1c0ec3599f4 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
> Cc: <stable@xxxxxxxxxxxxxxx> # v5.4+
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
Applied to fscrypt.git#master for 5.6.
- Eric
