All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Jeff Layton <jlayton@kernel.org>
Cc: Xiubo Li <xiubli@redhat.com>, 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: Sat, 26 Feb 2022 15:06:18 +0000	[thread overview]
Message-ID: <87v8x1sm51.fsf@brahms.olymp> (raw)
In-Reply-To: <57461c8994f5eb15409ae1cfe452b3d6b2263645.camel@kernel.org> (Jeff Layton's message of "Fri, 25 Feb 2022 15:57:34 -0500")

Jeff Layton <jlayton@kernel.org> writes:

> On Thu, 2022-02-24 at 11:21 +0000, 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;
>> +		}
>
> Where does 189 come from? You probably want to use CEPH_NOHASH_NAME_MAX.
>

Yeah, this is just a temporary workaround while the support for altnames
isn't implemented in snapshots.  (189 is the max size that will result in
a base64-encoded that is < MAX_NAME; 190 will be result in a filename that
is too long).

>>  	} 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);
>> +
>
> This looks hacky, but I just caught up on the discussion between you and
> Xiubo, so I assume you're addressing that.

Right, I still need to investigate this further.  It may actually be a bug
somewhere else.  Right now I was trying to get the MDS code written and
decided to look at this later.  I just thought I could send out this RFC
anyway in case someone had an idea -- and Xiubo already gave some
suggestions (which I still have to look at...).

>
>>  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);
>
> Can a snapdir inode outlive its parent?

Good question.  That actually occurred to me and I assumed it can not.
But maybe a better/safer option is to create a new copy of fscrypt_auth
into the snapdir and kfree it here.

Cheers,
-- 
Luís

>
>>  #endif
>>  	fscrypt_free_inode(inode);
>>  	kmem_cache_free(ceph_inode_cachep, ci);
>
> -- 
> Jeff Layton <jlayton@kernel.org>


      reply	other threads:[~2022-02-26 15:06 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
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 [this message]

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=87v8x1sm51.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.