Top level filenames not encrypted

[wpwoodjr]

Here's what I did:

test@test2:~$ mkdir t1

test@test2:~$ fscrypt encrypt t1
Should we create a new protector? [y/N] n
Enter login passphrase for test: 
"t1" is now encrypted, unlocked, and ready for use.

Then I went to Ubuntu's file manager and copied a directory named ums into t1.

test@test2:~$ ls t1 -lat
total 12
drwx------  3 test test 4096 Apr  1 13:20 .
drwxr-xr-x 29 test test 4096 Apr  1 13:19 ..
drwxr-xr-x  2 test test 4096 Mar 26 19:47 ums

After locking t1, ums is still visible as the file name:

test@test2:~$ sudo fscrypt lock --user=test t1
Encrypted data removed from filesystem cache.
"t1" is now locked.

test@test2:~$ ls t1 -lat
total 12
drwx------  3 test test 4096 Apr  1 13:20 .
drwxr-xr-x 29 test test 4096 Apr  1 13:19 ..
drwxr-xr-x  2 test test 4096 Mar 26 19:47 ums

But filenames in ums are encrypted:

test@test2:~$ ls t1/ums -lat
total 257112
drwx------ 3 test test      4096 Apr  1 13:20 ..
-rw-rw-r-- 1 test test       874 Mar 26 19:59 zpPsO8U0q1+FLq9FTdQsQ0Ja4itGmLJ7e0v2bTn9FRF
drwxr-xr-x 2 test test      4096 Mar 26 19:47 .
-rw-rw-r-- 1 test test        18 Mar 26 18:53 2qT,kZSHQ4z2UzAjXtkc7gHhnJPp7lyIXn1wQY+1RKL
-rw-rw-r-- 1 test test        43 Mar 26 18:37 JAbm,ev+bf5jyulBzNo22q,7wzq8Wb5a7QnAiRldPgK
-rwxrwxr-x 1 test test       413 Mar 26 18:36 oXTqSCsudcq0YCOuMcQGMIX3yxDPNMkMElyE6neHb9H
-rw-rw-r-- 1 test test      9283 Mar 26 18:36 0biVh,8CLUua,NV0fvC1cdPq04F7,lpGT8W0Ny5kWzI
-rwxrwxr-x 1 test test       946 Mar 26 18:36 Ba5nnF+Oi+7iyTMV0v6fh6Gp8AVfm4Gg8gctP0+HMfC
-rwxrwxr-x 1 test test       222 Mar 26 18:36 BBKQz3sskDll73UDuM,LlWcrtTOkpnj+VHx,t69Qb4N
-rw-rw-r-- 1 test test       585 Mar 26 18:36 cJF2c0vq,iiTocTFitbOIUqHMzo,J88h7HwsdOfszAL
-rwxrwxr-x 1 test test      1912 Mar 26 18:36 GKVJr25cM4X4aH+EEFCGJs2358aVm+hNnzwmD5sC90L
-rw-r--r-- 1 test test 263225531 Mar 26 18:25 UeHG,4aoK8GfN0mKEcZt5wqN8j+bmvtT9U7ApuURgSB

Now I can create files in t1 but not read them:

test@test2:~$ touch t1/test

test@test2:~$ ls -lat t1
total 12
drwx------  3 test test 4096 Apr  1 13:23 .
-rw-r--r--  1 test test    0 Apr  1 13:23 test
drwxr-xr-x 29 test test 4096 Apr  1 13:19 ..
drwxr-xr-x  2 test test 4096 Mar 26 19:47 ums

test@test2:~$ cat t1/test
cat: t1/test: Required key not available

Version info:

$ fscrypt --version
fscrypt - A tool for managing Linux filesystem encryption

Version:
  v0.2.6

Compiled:
  2020-02-11 08:08:48 +0000 UTC

Hope this helps!

[ebiggers]

This is expected if any process still has the directory t1 open. Do you have any idea why that might be the case for you? Perhaps your file manager still has it open? You could try checking with lsof.

(Note that with v1 policies which you're using, fscrypt can't really detect whether the directory was properly locked or not. If you were using a v2 encryption policy instead, which is recommended on kernel v5.4 or later, fscrypt would show an error message about the directory still being in-use.)

[wpwoodjr]

I closed the file manager. lsof reports no open files:

test@test2:~$ pwd
/home/test
test@test2:~$ lsof|grep /home/test/t1

I can still see the stuff in t1:

test@test2:~$ touch t1/test2
test@test2:~$ ls t1
test  test2  ums

[wpwoodjr]

Unlocked and re-locked t1, now all is good:

test@test2:~$ fscrypt unlock t1
Enter login passphrase for test: 
"t1" is now unlocked and ready for use.
test@test2:~$ cat t1/test2
test@test2:~$ sudo fscrypt lock --user=test t1
[sudo] password for test: 
Encrypted data removed from filesystem cache.
"t1" is now locked.
test@test2:~$ ls t1
816E,KVeReveNReYqcUFWXy8Ws2AbbbfVqqgG1iPDHP  R9o4COcdC3lf6Elnk5+ogC9NSSGVSuu3MPfMTALqxtM
OC3AVLTIq8l,nkfMyDDVNaMBR5tr+q7hJdRAemZWpgO

[ebiggers]

Yes, it's necessary to run fscrypt lock again after closing the directory, since closing the directory by itself (even if fscrypt lock was run previously) isn't guaranteed to lock it.

For v1 policies it's also needed to run fscrypt unlock before the second fscrypt lock, since fscrypt can't tell whether a v1-encrypted directory was incompletely locked vs. fully locked. It can tell with v2.

[wpwoodjr]

BTW, off-topic... I view it as worth noting that in comparison with ecryptfs, fscrypt cannot back up locked files, while ecryptfs can. In my opinion this is a substantial benefit of ecryptfs - am I missing something?

[ebiggers]

You're not really missing anything. eCryptfs uses filesystem stacking to implement encryption on top of encryption-unaware filesystems. That approach has a lot of performance and correctness disadvantages, which have made the main eCryptfs users switch to fscrypt or dm-crypt. However, it does have the advantage that backing up locked files works "naturally".

It would be possible (though somewhat difficult) to add kernel APIs that allow backup of locked fscrypt-encrypted files. But not too many people have been asking for this, since unlocked files can be backed up instead. So it's not currently a priority.

[ebiggers]

Filed #215 to track a possible usability improvement when locking v1-encrypted directories.

[jeremyakers]

I'm migrating from an older version of Ubuntu to 22.04 LTS and I'm trying to migrate away from eCryptfs for home directory encryption to fscrypt and I'm experiencing this same issue. Is there a way to force the home directory to auto-lock when the user logs out?