Tasks #63303
openTasks #63293: Implement fscrypt in libcephfs and cephfs-fuse
Add multi-user support for key claim
0%
Description
-Follow semantics for removal here: https://docs.kernel.org/filesystems/fscrypt.html#fs-ioc-remove-encryption-key
and
https://docs.kernel.org/filesystems/fscrypt.html#fs-ioc-remove-encryption-key-all-users
Handle busy case:
https://github.com/ceph/ceph/pull/52172/files#diff-27ee28966b05e5763e76677ae87f8626985eae114814c25bdc45eef15c3455f0R1035
Updated by Christopher Hoffman 7 months ago
- Subject changed from Add multi-user support for key removal to Add multi-user support for key claim
Updated by Christopher Hoffman 4 months ago
- Status changed from New to In Progress
Updated by Christopher Hoffman 4 months ago
- Description updated (diff)
Multiple user support added. Multiple users can perform unlock on same dir. As each unlock happens, user claim is added via id to a running list. When locked, user is removed from list and if last, locks dir.
TODO: if last claim, ensure no open handles exist for subtree. See: FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY
Updated by Venky Shankar 4 months ago
Christopher Hoffman wrote:
Multiple user support added. Multiple users can perform unlock on same dir. As each unlock happens, user claim is added via id to a running list. When locked, user is removed from list and if last, locks dir.
TODO: if last claim, ensure no open handles exist for subtree. See: FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY
In the water cooler that Chris presented, the users list isn't persisted anywhere and kept in memory. Chris mentioned that this is done in the initial implementation and probably should be persisted by the MDS.
Updated by Venky Shankar 4 months ago
Venky Shankar wrote:
Christopher Hoffman wrote:
Multiple user support added. Multiple users can perform unlock on same dir. As each unlock happens, user claim is added via id to a running list. When locked, user is removed from list and if last, locks dir.
TODO: if last claim, ensure no open handles exist for subtree. See: FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY
In the water cooler that Chris presented, the users list isn't persisted anywhere and kept in memory. Chris mentioned that this is done in the initial implementation and probably should be persisted by the MDS.
OK, so this ins't really required. I was looking at a different thing. Local key storage is what's currently done in the kclient.