Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2260297pxm; Fri, 4 Mar 2022 12:32:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJzc/gl2jQqapwa612GiYU0LdgSFd8T9FsfGJqm52EHnDZJf42PR0189sirbQ9jUQJcWNIdJ X-Received: by 2002:a17:90b:4c84:b0:1be:fe4f:28a1 with SMTP id my4-20020a17090b4c8400b001befe4f28a1mr460020pjb.42.1646425962988; Fri, 04 Mar 2022 12:32:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646425962; cv=none; d=google.com; s=arc-20160816; b=nFlE+gWrj5+SoHqnId3ewa8+HGXDCnyyMdicVePI2doppel/Fypt1vElWiWmHqjlNY pAHsUH71YeY8OXRjNBz3v4L/28blQzrKIR+V81+XNhJ0791AIuNNY2qWFIHYVBEq3oFn NsB6h4qTdpZhOgDJrl+cJcP1g/rUw2XDCPwWl15+KiN9KevTIJoYyoRyPkbhlh/10C+P gJ062maU6fgbk7xz4eU7u++VO/4tGjdMIN71CVEx/4GAA64ES/uFzFkMuP2A7iU+EyMG YDRvEw77ILp0A6slTgw+eV23ftrc42oO3nXWcqZ6hv615y+Vn7eT8y5o8qlWznaZ/zF1 S05A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=sJU8rDeWAT193Yfph/0d0vtc+Nis186c9MnEIscGlO4=; b=yHRdWHo6U02ddC3nc+/bXXeF1cCtHtfRE3K5qLGaJysSSWd4BdV0wCf3vF3kjT8GZc mfG4GU1fAMWs2sHNgNr/ECs2PFHyoptPyM86r/P15k3gyvWTOP+flGwtEbYsAdX6QKaA O1rIHR04sdRJ6wlDPbYgylwQQmnsM3OXYFzJQgUOEpEWk3LJp792PilIIZ0f3PuLmx51 zp4sAzlqpo0BD6UOWzOY0/kqu5AiKt9vBY3ROZwCnH2C5cvOtiZIbO/kaYFfvRkO926V cyANeG2bJ/EwsmLmL4ZIz+naUzpI+VsDZ+QEsvVhL2UVow3FvLvFNscfdVvjjTKTeEGU b2NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qsuplynD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id u9-20020a170903124900b001517bb91d95si5576227plh.140.2022.03.04.12.32.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 12:32:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qsuplynD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4CF1621EBBF; Fri, 4 Mar 2022 11:37:10 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241576AbiCDS0j (ORCPT + 99 others); Fri, 4 Mar 2022 13:26:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232870AbiCDS0h (ORCPT ); Fri, 4 Mar 2022 13:26:37 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58E8F1BD9AB; Fri, 4 Mar 2022 10:25:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EB4D1B82A88; Fri, 4 Mar 2022 18:25:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11098C340E9; Fri, 4 Mar 2022 18:25:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646418346; bh=l0FlQzAMsxaYplXdIdyynX482admzfc4/JVxFMppzT8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=qsuplynDE6XcT1GR1C2LVZUv4vKClCPjkbdAokkOjqZD4uKxHJ4Bf8FQxQhT4Ej1t oN0VvBtqXDdhKBkFIWeoHsDx1Rqx6XC2LWiRIukNB9ebyYfqLdGfPS7aUVcXzJyeUG //fZItt7kucmDN8TsCk3ss5DgaySF0a7vKgsCjSUxXjdzJMjJ5BkFUrnSSkwIu1c1J MZNv/vmXgodsJmjI66OItdbZMxVDKB76KRXb4D8EYPLk+73udYSqix8ejUJG15aBti O7g/kcfXsUksH3304YHIMINjEbEX9rPabPIswI0obaeI4RwdgQ9H5YOaAcDdbZTEND YgWZuj9lJGzmA== Message-ID: Subject: Re: [PATCH 3/3] ceph: add support for encrypted snapshot names From: Jeff Layton To: =?ISO-8859-1?Q?Lu=EDs?= Henriques , Xiubo Li , Ilya Dryomov Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 04 Mar 2022 13:25:44 -0500 In-Reply-To: <20220304161403.19295-4-lhenriques@suse.de> References: <20220304161403.19295-1-lhenriques@suse.de> <20220304161403.19295-4-lhenriques@suse.de> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-03-04 at 16:14 +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 > --- > fs/ceph/dir.c | 9 +++++++++ > fs/ceph/inode.c | 13 +++++++++++++ > 2 files changed, 22 insertions(+) > > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c > index 934402f5e9e6..17d2f18a1fd1 100644 > --- a/fs/ceph/dir.c > +++ b/fs/ceph/dir.c > @@ -1069,6 +1069,15 @@ 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); > + /* > + * Encrypted snapshots require d_revalidate to force a > + * LOOKUPSNAP to cleanup dcache > + */ > + if (IS_ENCRYPTED(dir)) { > + spin_lock(&dentry->d_lock); > + dentry->d_flags |= DCACHE_NOKEY_NAME; > + spin_unlock(&dentry->d_lock); > + } > } 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; > diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c > index 8b0832271fdf..357335a11384 100644 > --- a/fs/ceph/inode.c > +++ b/fs/ceph/inode.c > @@ -182,6 +182,19 @@ struct inode *ceph_get_snapdir(struct inode *parent) > ci->i_rbytes = 0; > ci->i_btime = ceph_inode(parent)->i_btime; > > + /* if encrypted, just borrow fscrypt_auth from parent */ > + if (IS_ENCRYPTED(parent)) { > + struct ceph_inode_info *pci = ceph_inode(parent); > + > + ci->fscrypt_auth = kmemdup(pci->fscrypt_auth, > + pci->fscrypt_auth_len, > + GFP_KERNEL); > + if (ci->fscrypt_auth) { > + inode->i_flags |= S_ENCRYPTED; > + ci->fscrypt_auth_len = pci->fscrypt_auth_len; > + } else > + dout("Failed to alloc memory for fscrypt_auth in snapdir\n"); Should we return an error in this case? > + } > if (inode->i_state & I_NEW) { > inode->i_op = &ceph_snapdir_iops; > inode->i_fop = &ceph_snapdir_fops; Seems simple and straightforward at first glance. -- Jeff Layton