All of lore.kernel.org
 help / color / mirror / Atom feed
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);
>>
>

  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.