From: "Luís Henriques" <lhenriques@suse.de>
To: Xiubo Li <xiubli@redhat.com>
Cc: Jeff Layton <jlayton@kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ceph: add support for encrypted snapshot names
Date: Fri, 25 Feb 2022 09:45:58 +0000 [thread overview]
Message-ID: <87lexzi8ix.fsf@brahms.olymp> (raw)
In-Reply-To: <27801620-b3fd-d556-c100-409632f91661@redhat.com> (Xiubo Li's message of "Fri, 25 Feb 2022 13:36:24 +0800")
Xiubo Li <xiubli@redhat.com> writes:
> On 2/24/22 7:21 PM, Luís Henriques wrote:
>> Since filenames in encrypted directories are already encrypted and shown
>> as a base64-encoded string when the directory is locked, snapshot names
>> should show a similar behaviour.
>>
>> Signed-off-by: Luís Henriques <lhenriques@suse.de>
>> ---
>> fs/ceph/dir.c | 15 +++++++++++++++
>> fs/ceph/inode.c | 10 +++++++++-
>> 2 files changed, 24 insertions(+), 1 deletion(-)
>>
>> Support on the MDS for names that'll be > MAX_NAME when base64 encoded is
>> still TBD. I thought it would be something easy to do, but snapshots
>> don't seem to make use of the CDir/CDentry (which is where alternate_name
>> is stored on the MDS). I'm still looking into this, but I may need some
>> help there :-(
>
> Yeah, good catch. The snapshot handler in MDS hasn't handled this case yet,
> though the kclient has passed it to MDS server.
>
> The snapshot alternate_name raw ciphertext should be stored in SnapInfo struct
> along with the 'name'.
>
>
>>
>> Cheers,
>> --
>> Luís
>>
>> diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
>> index a449f4a07c07..20ae600ee7cd 100644
>> --- a/fs/ceph/dir.c
>> +++ b/fs/ceph/dir.c
>> @@ -1065,6 +1065,13 @@ static int ceph_mkdir(struct user_namespace *mnt_userns, struct inode *dir,
>> op = CEPH_MDS_OP_MKSNAP;
>> dout("mksnap dir %p snap '%pd' dn %p\n", dir,
>> dentry, dentry);
>> + /* XXX missing support for alternate_name in snapshots */
>> + if (IS_ENCRYPTED(dir) && (dentry->d_name.len >= 189)) {
>> + dout("encrypted snapshot name too long: %pd len: %d\n",
>> + dentry, dentry->d_name.len);
>> + err = -ENAMETOOLONG;
>> + goto out;
>> + }
>
> We should fix the MDS side bug and then this workaroud will be no needed.
Yep, I've been looking into that too but it's taking a bit to understand
all that's going on there. I'm still trying, but the MDS code (and C++ in
general) is a bit... challenging.
Cheers,
--
Luís
>
> - Xiubo
>
>> } else if (ceph_snap(dir) == CEPH_NOSNAP) {
>> dout("mkdir dir %p dn %p mode 0%ho\n", dir, dentry, mode);
>> op = CEPH_MDS_OP_MKDIR;
>> @@ -1109,6 +1116,14 @@ static int ceph_mkdir(struct user_namespace *mnt_userns, struct inode *dir,
>> !req->r_reply_info.head->is_target &&
>> !req->r_reply_info.head->is_dentry)
>> err = ceph_handle_notrace_create(dir, dentry);
>> +
>> + /*
>> + * If we have created a snapshot we need to clear the cache, otherwise
>> + * snapshot will show encrypted filenames in readdir.
>> + */
>> + if (ceph_snap(dir) == CEPH_SNAPDIR)
>> + d_drop(dentry);
>> +
>> out_req:
>> ceph_mdsc_put_request(req);
>> out:
>> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
>> index 8b0832271fdf..080824610b73 100644
>> --- a/fs/ceph/inode.c
>> +++ b/fs/ceph/inode.c
>> @@ -182,6 +182,13 @@ struct inode *ceph_get_snapdir(struct inode *parent)
>> ci->i_rbytes = 0;
>> ci->i_btime = ceph_inode(parent)->i_btime;
>> + /* if encrypted, just borough fscrypt_auth from parent */
>> + if (IS_ENCRYPTED(parent)) {
>> + struct ceph_inode_info *pci = ceph_inode(parent);
>> + inode->i_flags |= S_ENCRYPTED;
>> + ci->fscrypt_auth_len = pci->fscrypt_auth_len;
>> + ci->fscrypt_auth = pci->fscrypt_auth;
>> + }
>> if (inode->i_state & I_NEW) {
>> inode->i_op = &ceph_snapdir_iops;
>> inode->i_fop = &ceph_snapdir_fops;
>> @@ -632,7 +639,8 @@ void ceph_free_inode(struct inode *inode)
>> kfree(ci->i_symlink);
>> #ifdef CONFIG_FS_ENCRYPTION
>> - kfree(ci->fscrypt_auth);
>> + if (ceph_snap(inode) != CEPH_SNAPDIR)
>> + kfree(ci->fscrypt_auth);
>> #endif
>> fscrypt_free_inode(inode);
>> kmem_cache_free(ceph_inode_cachep, ci);
>>
>
next prev parent reply other threads:[~2022-02-25 9:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 11:21 [RFC PATCH] ceph: add support for encrypted snapshot names Luís Henriques
2022-02-25 5:36 ` Xiubo Li
2022-02-25 9:45 ` Luís Henriques [this message]
2022-02-25 6:55 ` Xiubo Li
2022-02-25 9:48 ` Luís Henriques
2022-02-25 10:42 ` Xiubo Li
2022-02-25 13:27 ` Luís Henriques
2022-02-26 6:52 ` Xiubo Li
2022-02-26 14:58 ` Luís Henriques
2022-02-28 0:42 ` Xiubo Li
2022-02-25 20:57 ` Jeff Layton
2022-02-26 15:06 ` Luís Henriques
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=87lexzi8ix.fsf@brahms.olymp \
--to=lhenriques@suse.de \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.