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 13:27:52 +0000	[thread overview]
Message-ID: <87czjbhy93.fsf@brahms.olymp> (raw)
In-Reply-To: <1945dae6-9c0d-4cf7-49d8-843ba15e1710@redhat.com> (Xiubo Li's message of "Fri, 25 Feb 2022 18:42:40 +0800")

Xiubo Li <xiubli@redhat.com> writes:

> On 2/25/22 5:48 PM, Luís Henriques wrote:
>> 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 :-(
>>>>
>>>> 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;
>>>> +		}
>>>>    	} 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.
>>>> +	 */
>>> Do you mean dencrypted filenames ?
>> What I see without this d_drop() is that, if I run an 'ls' in a snapshot
>> directory immediately after creating it, the filenames in that snapshot
>> will be encrypted.  Maybe there's a bug somewhere else and this d_drop()
>> isn't the right fix...?
>
> Maybe should fix this in ceph_fill_trace() in

Hmm... maybe, I'll have to check.  Thank's for the suggestion.  I'll try
to investigate this before sending a new revision which, hopefully, will
have some MDS-side changes to support the altname (which I'm still trying
to untangle).

Cheers,
-- 
Luís

>
>        } else if ((req->r_op == CEPH_MDS_OP_LOOKUPSNAP ||... {
>
>        }
>
> ?
>
> I still haven't gotten where will encrypt it yet in mksnap case. Because the MDS
> will set the 'rinfo->head->is_target' but won't set the
> 'rinfo->head->is_dentry', so in this case the dentry should keep the 
> human readable name.
>
> - Xiubo
>
>
>> Cheers,
>


  reply	other threads:[~2022-02-25 13:27 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
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 [this message]
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=87czjbhy93.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.