Re: ceph-mds infrastructure for fscrypt

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

 



On Fri, 2021-04-30 at 07:45 -0700, Patrick Donnelly wrote:
> On Fri, Apr 30, 2021 at 7:33 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > We specifically need this for directories and symlinks during pathwalks
> > too. Eventually we may also want to encrypt certain data for other inode
> > types as well (e.g. block/char devices). That's less critical though.
> > 
> > The problem with fetching it after the inode is first instantiated is
> > that we can end up recursing into a separate request while encoding a
> > path. For instance, see this stack trace that Luis reported:
> > https://lore.kernel.org/ceph-devel/53d5bebb28c1e0cd354a336a56bf103d5e3a6344.camel@xxxxxxxxxx/T/#m0f7bbed6280623d761b8b4e70671ed568535d7fa
> > 
> > While that implementation stored the context in an xattr, the problem
> > isstill the same if you have to fetch the context in the middle of
> > building a path. The best solution is just to always ensure it's
> > available.
> 
> Got it. Splitting the struct makes sense then. The pin cap would be
> suitable for the immutable encryption context (if truly
> immutable?).Otherwise maybe the Axs cap?
> 

Ok. In that case, then we probably need to put the context blob under
AUTH caps so we can ensure that it's consulted during the permission
checks for pathwalks. The size will need to live under FILE.

Now for the hard part...what do we name these fields?

    fscrypt_context
    fscrypt_size

...or maybe...

    fscrypt_auth
    fscrypt_file

Since they'll be vector blobs, we can version these too so that we can
add other fields later if the need arises (even for non-fscrypt stuff).
Maybe we could consider:

    client_opaque_auth
    client_opaque_file

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux