Re: [RFC PATCH v7 07/24] ceph: add fscrypt_* handling to caps.c

[Jeff Layton <jlayton@kernel.org>]

On Sun, 2021-07-11 at 18:00 -0500, Eric Biggers wrote:
> On Fri, Jun 25, 2021 at 09:58:17AM -0400, Jeff Layton wrote:
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  fs/ceph/caps.c | 62 +++++++++++++++++++++++++++++++++++++++-----------
> >  1 file changed, 49 insertions(+), 13 deletions(-)
> > 
> > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > index 038f59cc4250..1be6c5148700 100644
> > --- a/fs/ceph/caps.c
> > +++ b/fs/ceph/caps.c
> > @@ -13,6 +13,7 @@
> >  #include "super.h"
> >  #include "mds_client.h"
> >  #include "cache.h"
> > +#include "crypto.h"
> >  #include <linux/ceph/decode.h>
> >  #include <linux/ceph/messenger.h>
> >  
> > @@ -1229,15 +1230,12 @@ struct cap_msg_args {
> >  	umode_t			mode;
> >  	bool			inline_data;
> >  	bool			wake;
> > +	u32			fscrypt_auth_len;
> > +	u32			fscrypt_file_len;
> > +	u8			fscrypt_auth[sizeof(struct ceph_fscrypt_auth)]; // for context
> > +	u8			fscrypt_file[sizeof(u64)]; // for size
> >  };
> 
> The naming of these is confusing to me.  If these are the fscrypt context and
> the original file size, why aren't they called something like fscrypt_context
> and fscrypt_file_size?
> 
> Also does the file size really need to be variable-length, or could it just be a
> 64-bit integer?
> 

Fscrypt is really a kernel client-side feature. Both of these new fields
are treated as opaque by the MDS and are wholly managed by the client.

We need two fields because they are governed by different cephfs
capabilities (aka "caps"). AUTH caps for the context and FILE caps for
the size. So we have two new fields -- fscrypt_file and fscrypt_auth. 

The size could be a __le64 or something, but I think it makes sense to
allow it to be opaque as we aren't certain what other info we might want
to keep in there. We might also want to encrypt the fscrypt_file field
to cloak the true size of a file from anyone without the key.

Now, all that said, the fact that the MDS largely handles truncation
poses some special challenges for the content encryption piece. We may
ultimately end up making this more special-purpose than it is now.
-- 
Jeff Layton <jlayton@kernel.org>