From: "Luís Henriques" <lhenriques@suse.de>
To: xiubli@redhat.com
Cc: jlayton@kernel.org, idryomov@gmail.com, vshankar@redhat.com,
ceph-devel@vger.kernel.org
Subject: Re: [PATCH v3 0/6] ceph: encrypt the snapshot directories
Date: Wed, 02 Mar 2022 15:40:16 +0000 [thread overview]
Message-ID: <87mti88isf.fsf@brahms.olymp> (raw)
In-Reply-To: <20220302121323.240432-1-xiubli@redhat.com> (xiubli@redhat.com's message of "Wed, 2 Mar 2022 20:13:17 +0800")
Hi Xiubo,
xiubli@redhat.com writes:
> From: Xiubo Li <xiubli@redhat.com>
>
> This patch series is base on the 'wip-fscrypt' branch in ceph-client.
I gave this patchset a try but it looks broken. For example, if 'mydir'
is an encrypted *and* locked directory doing:
# ls -l mydir/.snap
will result in:
fscrypt (ceph, inode 1099511627782): Error -105 getting encryption context
My RFC patch had an issue that I haven't fully analyzed (and that I
"fixed" using the d_drop()). But why is the much simpler approach I used
not acceptable? (I.e simply use fscryt_auth from parent in
ceph_get_snapdir()).
> V3:
> - Add more detail comments in the commit comments and code comments.
> - Fix some bugs.
> - Improved the patches.
> - Remove the already merged patch.
>
> V2:
> - Fix several bugs, such as for the long snap name encrypt/dencrypt
> - Skip double dencypting dentry names for readdir
>
> ======
>
> NOTE: This patch series won't fix the long snap shot issue as Luis
> is working on that.
Yeah, I'm getting back to it right now. Let's see if I can untangle this
soon ;-)
Cheers,
--
Luís
> Xiubo Li (6):
> ceph: fail the request when failing to decode dentry names
> ceph: do not dencrypt the dentry name twice for readdir
> ceph: add ceph_get_snap_parent_inode() support
> ceph: use the parent inode of '.snap' to dencrypt the names for
> readdir
> ceph: use the parent inode of '.snap' to encrypt name to build path
> ceph: try to encrypt/decrypt long snap name
>
> fs/ceph/crypto.c | 95 ++++++++++++++++++++++++++++++++---
> fs/ceph/crypto.h | 10 +++-
> fs/ceph/dir.c | 98 ++++++++++++++++++++++--------------
> fs/ceph/inode.c | 115 ++++++++++++++++++++++++++++++++++++++-----
> fs/ceph/mds_client.c | 57 +++++++++++++--------
> fs/ceph/mds_client.h | 3 ++
> fs/ceph/snap.c | 24 +++++++++
> fs/ceph/super.h | 2 +
> 8 files changed, 327 insertions(+), 77 deletions(-)
>
> --
> 2.27.0
>
next prev parent reply other threads:[~2022-03-02 15:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 12:13 [PATCH v3 0/6] ceph: encrypt the snapshot directories xiubli
2022-03-02 12:13 ` [PATCH v3 1/6] ceph: fail the request when failing to decode dentry names xiubli
2022-03-02 12:13 ` [PATCH v3 2/6] ceph: do not dencrypt the dentry name twice for readdir xiubli
2022-03-02 12:13 ` [PATCH v3 3/6] ceph: add ceph_get_snap_parent_inode() support xiubli
2022-03-02 12:13 ` [PATCH v3 4/6] ceph: use the parent inode of '.snap' to dencrypt the names for readdir xiubli
2022-03-02 12:13 ` [PATCH v3 5/6] ceph: use the parent inode of '.snap' to encrypt name to build path xiubli
2022-03-02 12:13 ` [PATCH v3 6/6] ceph: try to encrypt/decrypt long snap name xiubli
2022-03-02 15:40 ` Luís Henriques [this message]
2022-03-02 16:58 ` [PATCH v3 0/6] ceph: encrypt the snapshot directories Luís Henriques
2022-03-03 2:49 ` Xiubo Li
2022-03-03 9:50 ` Luís Henriques
2022-03-03 2:57 ` Xiubo Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mti88isf.fsf@brahms.olymp \
--to=lhenriques@suse.de \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=vshankar@redhat.com \
--cc=xiubli@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.