Messages in this thread | | | Subject | Re: [RFC PATCH v2 0/3] ceph: add support for snapshot names encryption | From | Xiubo Li <> | Date | Thu, 17 Mar 2022 19:28:45 +0800 |
| |
On 3/17/22 7:11 PM, Luís Henriques wrote: > Xiubo Li <xiubli@redhat.com> writes: > >> On 3/17/22 6:01 PM, Jeff Layton wrote: >>> I'm not sure we want to worry about .snap directories here since they >>> aren't "real". IIRC, snaps are inherited from parents too, so you could >>> do something like >>> >>> mkdir dir1 >>> mkdir dir1/.snap/snap1 >>> mkdir dir1/dir2 >>> fscrypt encrypt dir1/dir2 >>> >>> There should be nothing to prevent encrypting dir2, but I'm pretty sure >>> dir2/.snap will not be empty at that point. >> If we don't take care of this. Then we don't know which snapshots should do >> encrypt/dencrypt and which shouldn't when building the path in lookup and when >> reading the snapdir ? > In my patchset (which I plan to send a new revision later today, I think I > still need to rebase it) this is handled by using the *real* snapshot > parent inode. If we're decrypting/encrypting a name for a snapshot that > starts with a '_' character, we first find the parent inode for that > snapshot and only do the operation if that parent is encrypted.
Yeah, this is correct. And in my previous patches it worked well.
> > In the other email I suggested that we could prevent enabling encryption > in a directory when there are snapshots above in the hierarchy.
I think this is incorrect. Or once there has a snapshot in the root directory, then you couldn't enable encryption any more in any subdirs ...
> But now > that I think more about it, it won't solve any problem because you could > create those snapshots later and then you would still need to handle these > (non-encrypted) "_name_xxxx" snapshots anyway.
You only need to take care of the *real* or local snapshots.
-- Xiubo
> > Cheers,
| |