On Mon, 2022-02-14 at 21:00 +0000, Luís Henriques wrote: > Jeff Layton <jlayton@xxxxxxxxxx> writes: > > > On Mon, 2022-02-14 at 17:57 +0000, Luís Henriques wrote: > > > Jeff Layton <jlayton@xxxxxxxxxx> writes: > > > > > > > This patchset represents a (mostly) complete rough draft of fscrypt > > > > support for cephfs. The context, filename and symlink support is more or > > > > less the same as the versions posted before, and comprise the first half > > > > of the patches. > > > > > > > > The new bits here are the size handling changes and support for content > > > > encryption, in buffered, direct and synchronous codepaths. Much of this > > > > code is still very rough and needs a lot of cleanup work. > > > > > > > > fscrypt support relies on some MDS changes that are being tracked here: > > > > > > > > https://github.com/ceph/ceph/pull/43588 > > > > > > > > > > Please correct me if I'm wrong (and I've a feeling that I *will* be > > > wrong): we're still missing some mechanism that prevents clients that do > > > not support fscrypt from creating new files in an encryption directory, > > > right? I'm pretty sure I've discussed this "somewhere" with "someone", > > > but I can't remember anything else. > > > > > > At this point, I can create an encrypted directory and, from a different > > > client (that doesn't support fscrypt), create a new non-encrypted file in > > > that directory. The result isn't good, of course. > > > > > > I guess that a new feature bit can be used so that the MDS won't allow any > > > sort of operations (or, at least, write/create operations) on encrypted > > > dirs from clients that don't have this bit set. > > > > > > So, am I missing something or is this still on the TODO list? > > > > > > (I can try to have a look at it if this is still missing.) > > > > > > Cheers, > > > > It's still on the TODO list. > > > > Basically, I think we'll want to allow non-fscrypt-enabled clients to > > stat and readdir in an fscrypt-enabled directory tree, and unlink files > > and directories in it. > > > > They should have no need to do anything else. You can't run backups from > > such clients since you wouldn't have the real size or crypto context. > > Yep, that makes sense. And do you think that adding a new feature bit is > the best way to sort this out, or did you had other solution in mind? > > I'll try to spend some time on this tomorrow. > Probably a new cephfs feature bit is fine, and indeed we already have one for fscrypt anyway. This can probably share a value with the ALTERNATE_NAME bit. -- Jeff Layton <jlayton@xxxxxxxxxx>
|