On Fri, Apr 30, 2021 at 6:45 AM Jeff Layton <jlayton@xxxxxxxxxx> 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 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
