Re: ceph-mds infrastructure for fscrypt

[Patrick Donnelly <pdonnell@redhat.com>]

On Fri, Apr 30, 2021 at 6:45 AM Jeff Layton <jlayton@redhat.com> wrote:
> > > The client can stuff that into the xattr blob when creating a new inode,
> > > and the MDS can scrape it out of that and move the data into the correct
> > > field in the inode. A setxattr on this field would update the new field
> > > too. It's an ugly interface, but shouldn't be too bad to handle and we
> > > have some precedent for this sort of thing.
> > >
> > > The rules for handling the new field in the client would be a bit weird
> > > though. We'll need to allow it to reading the fscrypt_ctx part without
> > > any caps (since that should be static once it's set), but the size
> > > handling needs to be under the same caps as the traditional size field
> > > (Is that Fsx? The rules for this are never quite clear to me.)
> > >
> > > Would it be better to have two different fields here -- fscrypt_auth and
> > > fscrypt_file? Or maybe, fscrypt_static/_dynamic? We don't necessarily
> > > need to keep all of this info together, but it seemed neater that way.
> >
> > I'm not seeing a reason to split the struct.
> >
>
> What caps should this live under? We have different requirements for
> different parts of the struct.
>
> 1) fscrypt context: needs to be always available, especially when an
> inode is initially instantiated, though it should almost always be
> static once it's set. The exception is that an empty directory can grow
> a new context when it's first encrypted, and we'll want other clients to
> pick up on this change when it occurs.

Do clients need to see this when not reading/writing to the file?

> 2) "real" size: needs to be under Fwx, I think (though I need to look
> more closely at the truncation path to be sure).

Frs would need the size as well.

> ...and that's not even considering what rules we might want in the
> future for other info we stuff into here. Given that the MDS needs to
> treat this as opaque, what locks/caps should cover this new field?

I think because the encryption context is used for reads/writes, it
can fall under the same lock domain as the file size. I don't see a
need (yet) for accessing e.g. the encrypted version/blocksize outside
of the Fsx cap. It's good to think about though and I wonder if anyone
else has thoughts on it.

-- 
Patrick Donnelly, Ph.D.
He / Him / His
Principal Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D