[LU-16374] Implement backup/restore of encrypted files

• Type: New Feature
• Resolution: Unresolved
• Priority: Minor
• Affects Version/s: Lustre 2.16.0
• Labels: usability
• Epic Link: Client side Encrypted backup/restore
• Assignee: Sebastien Buisson
• Reporter: Sebastien Buisson

Description

Implement backup/restore of encrypted files, according the the HLD as available at https://datadirectnetworks-my.sharepoint.com/:w:/g/personal/sbuisson_ddn_com/EeWD3Q7Ku69Anntda03QPDUBs6oxRCxtlxELM7xxy-S1qQ

This effort can be divided into the following steps:

• security.encdata xattr getting at ldiskfs level
• security.encdata xattr setting at ldiskfs level
• security.encdata xattr getting at llite level
• security.encdata xattr setting at llite level
• Lustre support for O_TMPFILE open flag
• lfs fscrypt read
• lfs fscrypt write
• tar modifications for backup/restore
• HSM POSIX copytool modifications for backup/restore

Issue Links

• is related to: LU-14677 lfs migrate/mirror of encrypted files
• is related to: LU-16259 HLD for encrypted backup/restore

Comments

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49456/
Subject: LU-16374 ldiskfs: implement security.encdata xattr
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d0a722cb8fb886380e24e8261e8efca09a3262d6

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/51640/
Subject: LU-16374 enc: rename O_FILE_ENC to O_CIPHERTEXT
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ac522557b1fe3ea2b7275fa6d5df73691b8d06db

[Andreas Dilger]

For reference, there was a discussion about fscrypt file backup and restore on the linux-ext4, linux-fscrypt, and linux-fsdevel mailing lists in "Backup/restore of fscrypt files and directories" and this also referenced other discussions "backup/restore of fscrypt files" and "fs: interface for directly reading/writing compressed data".

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51640
Subject: LU-16374 enc: rename O_FILE_ENC to O_CIPHERTEXT
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ecfbc16ad38eb514fb14d1919fdc4f24a96fd403

[Andreas Dilger]

I noticed while running strace tar that it is always opening files with the equivalent of O_FILE_ENC:

#define O_FILE_ENC              (O_NOCTTY | O_NDELAY)

openat(AT_FDCWD, "/mnt/testfs/sparse", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC) = 3

because of include/uapi/asm-generic/fcntl.h:

#ifndef O_NDELAY
#define O_NDELAY        O_NONBLOCK
#endif

I think this is mostly saved by the additional requirement for O_DIRECT (which is not part of O_FILE_ENC, but should be). We should consider changing this to use a different flag combination for O_FILE_ENC to avoid the risk of accidental issues if tar ever starts reading with O_DIRECT before we can get the xattr handling implemented.

One possibility includes O_DSYNC, which doesn't make much sense for O_RDONLY files, but would force writes on encrypted restore to be synchronous. With O_DIRECT and large enough writes (32MB?) that might be OK, but not ideal for small files. Another possibility is O_APPEND, which would prevent multiple writers to an encrypted file during restore, but would otherwise be OK. I haven't looked at any of the options in detail yet, just wanted to point out this issue.

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49945/
Subject: LU-16374 enc: align Base64 encoding with RFC 4648 base64url
Project: fs/lustre-release
Branch: b2_15
Current Patch Set:
Commit: 3a12414a169a6199a5d187ed801aa9577c9f1192

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50561
Subject: LU-16374 ldiskfs: implement backup/restore of enc files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b9338f73057f3f11faa8946fccbac657cf52ee8b

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49410/
Subject: LU-16374 ldiskfs: round-up enc file size
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ea95b07c6c3869dad6bd925754dec5ea173a3c43

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49945
Subject: LU-16374 enc: align Base64 encoding with RFC 4648 base64url
Project: fs/lustre-release
Branch: b2_15
Current Patch Set: 1
Commit: d26efca6180f3997d89d9853a3891ee13115d5e8

[Andreas Dilger]

Sebastien, can you please add a test case for the bas64 vs. base64url compatibility.

Best would be to update test32_newtarball() to add a 2.14.0 directory with data-only encryption and a 2.15.0 directory with filename encryption (with base64 name encoding) enabled. The test_32 script should contain an "ls -l" of the encrypted directories to verify they are all unchanged. This listing would fail for the 2.15.0 filename encrypted directory with a master client due to the base64url encoding, unless llite.*.filename_enc_use_old_base64=1 is set.