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. -- Jeff Layton <jlayton@xxxxxxxxxx>
