[LU-13717] Client-side encryption - support file name encryption

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.15.0
• Labels: encryption sec
• Assignee: Sebastien Buisson
• Reporter: Sebastien Buisson

Description

This ticket is a place-holder to describe work to be done for client-side file name encryption. This is a follow-up of LU-12275, so all principles and concepts detailed there are still valid.

In particular, filename encryption principles are explained in this document:
https://jira.whamcloud.com/secure/attachment/32657/lustre_encryption_modes_usage.txt

Further details will be added as the feature design makes progress.

Issue Links

• is related to: LU-15027 sanity-sec: crash in __list_add_valid() during sanity-sec test_47
• is related to: LU-15406 Using the native fscrypt for Ubuntu20 5.4 kernel fails several migration test
• is related to: LU-15407 fscrypt does not work on Ubuntu 5.8 kernel
• is related to: LU-15810 Migrated encrypted directory lacks on-disk encryption flag and context
• is related to: LU-15922 Interop: sanity-sec test_46: File name too long
• is related to: LU-15848 ldiskfs: escape encrypted file names
• is related to: LU-15827 BUG: KASAN: slab-out-of-bounds in osd_ldiskfs_filldir+0x16c2/0x1860 [osd_ldiskfs]
• is related to: LU-16085 Ubuntu 22.04 sanityn test_106c: supported stx_attributes: got '2030', expected '30'
• is related to: LU-15928 pass key length as part of index API
• is related to: LU-15787 clients built without encryption support can corrupt encrypted directories
• is related to: LU-15855 Return -ENOKEY to encrypt-unaware clients if filename is missing
• is related to: LU-15911 Make enable_filename_encryption tunable only available with embedded llcrypt
• is related to: LU-12275 Client-side file data encryption
• is related to: LU-14677 lfs migrate/mirror of encrypted files

Comments

[Andreas Dilger]

e2fsprogs be included in e2fsprogs-1.46.2.wc4

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" merged in patch https://review.whamcloud.com/45212/
Subject: LU-13717 sec: process Lustre enc inodes as normal enc inodes
Project: tools/e2fsprogs
Branch: master-lustre
Current Patch Set:
Commit: 35ce354fa5688625961a62fae8d26f826b015593

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" merged in patch https://review.whamcloud.com/45289/
Subject: LU-13717 sec: support encrypted files handling in pfsck mode
Project: tools/e2fsprogs
Branch: master-lustre
Current Patch Set:
Commit: d35469d6c41a90ebeca121d3e5ec709cfc967cb8

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/45221/
Subject: LU-13717 sec: missing defs in includes for client encryption
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 79ac7c144539e0d964db329c341ebf30a8472f5c

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45289
Subject: LU-13717 sec: support encrypted files handling in pfsck mode
Project: tools/e2fsprogs
Branch: master-lustre
Current Patch Set: 1
Commit: ef01ec0a4ffc6c0de9dfc1377fa3880611b5e664

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45221
Subject: LU-13717 sec: missing defs in includes for client encryption
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 089ce9b3939c9f6aad257c61987e7b8d18469b22

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45212
Subject: LU-13717 sec: process Lustre enc inodes as normal enc inodes
Project: tools/e2fsprogs
Branch: master-lustre
Current Patch Set: 1
Commit: 2f2ab907b1f0d3a77b69c754aa03c71d580f7fd4

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45211
Subject: LU-13717 ldiskfs: set LDISKFS_ENCRYPT_FL on encrypted files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 946e64754846d5672387323ff482e2379df977e0

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45163
Subject: LU-13717 llite: encoded ciphertext name longer than NAME_MAX
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1fa416289e3ae7a9d3bef15a194c2b5fd54dded2

[Sebastien Buisson]

Regarding access to 2.15 encrypted directories from older clients, I tested with a 2.12 client and a 2.14 client. I tried to list content of a directory for which I know for sure some names have illegal characters (as told so by e2fsck), and the result is the same for both versions:

# ls -li /testfs/vault
total 0
144115238860527809 -rw-r--r-- 1 root root 0 Sep 28 15:32 ??????U??e?<?g?????n?G???YK$8???
144115238860527803 -rw-r--r-- 1 root root 0 Sep 28 15:32 =o?"????v????R??XM?????????n?=J?,?
144115238860527801 -rw-r--r-- 1 root root 0 Sep 28 15:32 J=M??%????9???Q{?q??,??rp.?hV;8l?
144115238860527804 -rw-r--r-- 1 root root 0 Sep 28 15:32 O?9????=?@??>O???????v??76<V???0&
144115238860527819 -rw-r--r-- 1 root root 0 Sep 29 15:37 \99D????5?N??Y??g_(?F%3(@x=M?1c???r???u??olJ????g?????{dNP??Wh??#?,F5C?(?3J???S;v??5??????"b???zZ????????n?|??I#??1f_9???BY????O!?3?B?4c??1?=o????a?????JV?Iv],???`z%??6?-k%??=M?=}?4????%??Um???????<6??T?~???#????B??b??????:.??A)
144115238860527806 -rw-r--r-- 1 root root 0 Sep 28 15:32 g??_??[??Z??p???;?_=}?.??aM????c0
144115238860527802 -rw-r--r-- 1 root root 0 Sep 28 15:32 ???T?"g??>??{??J???8?;??e???%]?_
144115238860527807 -rw-r--r-- 1 root root 0 Sep 28 15:32 ???????sg??=J?zu????q????????7?#G
144115238860527805 -rw-r--r-- 1 root root 0 Sep 28 15:32 ????????Q???????0=@as?y6?J?[?p???
144115238860527810 -rw-r--r-- 1 root root 0 Sep 28 15:32 ???*1??`????p????PI9?=?"?????????
144115238860527808 -rw-r--r-- 1 root root 0 Sep 28 15:32 ?:????d????z?????a?p???Jh???????

So it does not blow up the client, but of course it is not possible to browse subdirectories for instance. This is fine, as the purpose of encryption is to limit access to those who do not have the key.
All encrypted names go through critical_encode() in 2.15 servers before being sent to the clients. As this routine escapes critical characters such as NULL, LF, CR, /, DEL and =, the names read by encryption-unaware clients are not that badly formed.

[Andreas Dilger]

Sebastien, I was just wondering what the interoperability is for filesystems that have encrypted filenames, but are accessed by an older client? Ideally, the older client could access the unencrypted parts of the filesystem normally, and would not "explode" if trying to access the encrypted directory tree (i.e. not LBUG/Oops when accessing a filename with a NUL byte in it). If there is such a problem accessing an encrypted directory by an old client, then it makes sense for the 2.15 MDS to return -ENOKEY to clients without the OBD_CONNECT2_ENCRYPT feature when accessing encrypted directories and files.

Separately, there is a question of what happens in the unusual case of an encrypted directory being accessed by an old MDS after a downgrade, whether by a new or old client? It looks like there is already an LMAI_ENCRYPT flag being stored on each file, so this should prevent major problems.