Hi Paul, On Tue, May 09, 2023 at 03:26:34PM +0100, Paul Gover wrote: > Apologies if this should be raised as an issue in git, or if it's been > discussed already (if so, I couldn't find it - I did try). > > Moving a file (mv) from an encrypted folder to a non-encrypted folder exhibits > surprising behaviour. The moved file is readable if the owner of the > encrypted folder is signed in. If not, you get a useless error message. > > In my case, filesystem F2FS, "packager"'s home directory is encrypted using > fscrypt and unlocked with the login password for "packager" as per fscrypt > documentation. > > The path to and including /usr/local/bin is not encrypted - only various home > directories. > > I have ~packager/test.file containing a line of text. > Signed in as packager: > cp test.file /usr/local/bin/test.file.copied > mv test.file /usr/local/bin/test.file.moved > Logged in on another tty as "paul", while packager is still logged in, > I can cat both files in /usr/local/bin and see the text as expected. > When packager logs out, however, > "cat /usr/local/bin/test.file.copied" produces the expected text. > "cat /usr/local/bin/tes.file.moved" produces > "cat: test.file.moved: Required key not available" > Sadly, it does not explain which key is required! > > This is on kernel 6.3.1, compiled with Clang and LTO=thin, on a Gentoo system, > but I'd hope that was irrelevant. > > I see similar issues have already been discussed, for example: > //lore.kernel.org/linux-fscrypt/20201031183551.202400-1-ebiggers@xxxxxxxxxx/#r > "fscrypt: return -EXDEV for incompatible rename or link into encrypted dir". > > //github.com/google/fscrypt/issues/124 > "Document mv behavior when using filesystem encryption" ought to cover the > case, but doesn't warn of the potential for confusion. > > My own thoughts on this: (a) I should have used "install" to copy the program > in question into /usr/local/bin! but (b) the current situation is very > confusing. I ran a test with "ln", and note that trying to create a hard link > in an encrypted directory to a file in an unencrypted one: > "link foo /usr/local/bin/target" fails with "Invalid cross-device link". > This seems to be desirable behaviour for the case of: > "mv foo /usr/local/bin", or alternatively treat it like a cross-device move, > and instead do a copy. This is working as intended. Unencrypted directories are allowed to contain encrypted files. It's only the other way around -- unencrypted files in encrypted directories -- that is not allowed. So, renaming an encrypted file into an unencrypted directory succeeds. I can understand how this can seem unexpected, but unencrypted directories do need to be able to contain encrypted directories, after all; otherwise nothing could ever be encrypted in the first place. The current behavior then results just from not treating directories specially, and just doing exactly what the user asked to do -- rename the given file. As for the "Required key not available" error message not telling you which key is meant, that's simply because the kernel only reports integer error codes (ENOKEY in this case). We can't do anything about that. - Eric
|