Message ID | 20200904160537.76663-1-jlayton@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | ceph+fscrypt: context, filename and symlink support | expand |
On Fri, Sep 04, 2020 at 12:05:19PM -0400, Jeff Layton wrote: > This is a second posting of the ceph+fscrypt integration work that I've > been experimenting with. The main change with this patch is that I've > based this on top of Eric's fscrypt-pending set. That necessitated a > change to allocate inodes much earlier than we have traditionally, prior > to sending an RPC instead of waiting on the reply. FWIW, if possible you should create a git tag or branch for your patchset. While just the mailed patches work fine for *me* for this particular patchset, other people may not be able to figure out what the patchset applies to. (In particular, it depends on another patchset: https://lkml.kernel.org/r/20200824061712.195654-1-ebiggers@kernel.org) > Note that this just covers the crypto contexts and filenames. I've also > added a patch to encrypt symlink contents as well, but it doesn't seem to > be working correctly. What about symlink encryption isn't working correctly? - Eric
On Mon, 2020-09-07 at 22:54 -0700, Eric Biggers wrote: > On Fri, Sep 04, 2020 at 12:05:19PM -0400, Jeff Layton wrote: > > This is a second posting of the ceph+fscrypt integration work that I've > > been experimenting with. The main change with this patch is that I've > > based this on top of Eric's fscrypt-pending set. That necessitated a > > change to allocate inodes much earlier than we have traditionally, prior > > to sending an RPC instead of waiting on the reply. > > FWIW, if possible you should create a git tag or branch for your patchset. > While just the mailed patches work fine for *me* for this particular patchset, > other people may not be able to figure out what the patchset applies to. > (In particular, it depends on another patchset: > https://lkml.kernel.org/r/20200824061712.195654-1-ebiggers@kernel.org) > I've tagged this out as 'ceph-fscrypt-rfc.2' in my kernel.org tree (the first posting is ceph-fscrypt-rfc.1). Note that this also is layered on top of David Howell's fscache rework, and the work I've done to adapt cephfs to that. > > Note that this just covers the crypto contexts and filenames. I've also > > added a patch to encrypt symlink contents as well, but it doesn't seem to > > be working correctly. > > What about symlink encryption isn't working correctly? What I was seeing is that after unmounting and mounting, the symlink contents would be gibberish when read by readlink(). I confirmed that the same crypttext that came out of fscrypt_encrypt_symlink() was being fed into fscrypt_get_symlink(), but the result from that came back as gibberish. I need to do a bit more troubleshooting, but I now wonder if it's due to the context handling being wrong when dummy encryption is enabled. I'll have a look at that soon. Thanks for the review so far!