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. > -- > Jeff Layton <jlayton@xxxxxxxxxx> OK, I've looked at the code and I've a patch that works (sort of). Here's what I've done: I'm blocking all the dangerous Ops (CEPH_MDS_OP_{CREATE,MKDIR,...}) early in the client requests handling code. I.e., returning -EROFS if the client session doesn't have the feature *and* the inode has fscrypt_auth set. It sort of works (I still need to find if I need any locks, that's black magic for me!), but it won't prevent a client from doing things like appending garbage to an encrypted file. Doing this will obviously make that file useless, but it's not that much different from non-encrypted files (sure, in this case it might be possible to recover some data). But I'm not seeing an easy way to caps into this mix. Cheers, -- Luís
