Re: [RFC PATCH v10 00/48] ceph+fscrypt: full support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux