From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79932C43461 for ; Wed, 16 Sep 2020 19:12:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DEA820708 for ; Wed, 16 Sep 2020 19:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600283531; bh=dIAu59T4SYU/adnWE9ylH53MOsWZJPlPNzf33P+w0G8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:List-ID:From; b=VqWoTFhrGDovLTKqmB1Ut452+gMsiFY7AWIpRoAJzx5o9RfBH87cuHg2dICmk8cOX 20hdde/dcbl6J+bvXStoAhytzq+BBEXHPAlBegtDwPVY/G0jYzNi8MLYzI7qOCuu2G 565dXcOG+HKT6ssptZvnPXiuH0YZT42oQ2IiYM9s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727521AbgIPTMJ (ORCPT ); Wed, 16 Sep 2020 15:12:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:56308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727332AbgIPRkk (ORCPT ); Wed, 16 Sep 2020 13:40:40 -0400 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4A8722228; Wed, 16 Sep 2020 12:18:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600258712; bh=dIAu59T4SYU/adnWE9ylH53MOsWZJPlPNzf33P+w0G8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=itdFKVte18xxHKQKEGBDOuEd+lfcVV0N1Kwkm+BDnOizG2ZdjWdfrsEcVVm4wOrFI GI4GMX2aRnIM0XULDX2My5Tbsk+KZwQn1De6LJED4xg3DI4Z4H0+VUE2afO1KWYTyX FuGV10umftDikdoyL2ZgI5TwZ/I6odqKK0QQbG+k= Message-ID: <6889fd7528052f014b4c7fe5b3ac0d0e22fa8cc0.camel@kernel.org> Subject: Re: [RFC PATCH v3 10/16] ceph: add routine to create context prior to RPC From: Jeff Layton To: Eric Biggers Cc: ceph-devel@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Date: Wed, 16 Sep 2020 08:18:30 -0400 In-Reply-To: <20200915013724.GJ899@sol.localdomain> References: <20200914191707.380444-1-jlayton@kernel.org> <20200914191707.380444-11-jlayton@kernel.org> <20200915013724.GJ899@sol.localdomain> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, 2020-09-14 at 18:37 -0700, Eric Biggers wrote: > On Mon, Sep 14, 2020 at 03:17:01PM -0400, Jeff Layton wrote: > > diff --git a/fs/ceph/crypto.h b/fs/ceph/crypto.h > > index b5f38ee80553..c1b6ec4b2961 100644 > > --- a/fs/ceph/crypto.h > > +++ b/fs/ceph/crypto.h > > @@ -11,6 +11,8 @@ > > #define CEPH_XATTR_NAME_ENCRYPTION_CONTEXT "encryption.ctx" > > > > void ceph_fscrypt_set_ops(struct super_block *sb); > > +int ceph_fscrypt_prepare_context(struct inode *dir, struct inode *inode, > > + struct ceph_acl_sec_ctx *as); > > > > #else /* CONFIG_FS_ENCRYPTION */ > > > > @@ -19,6 +21,12 @@ static inline int ceph_fscrypt_set_ops(struct super_block *sb) > > return 0; > > } > > > > +static inline int ceph_fscrypt_prepare_context(struct inode *dir, struct inode *inode, > > + struct ceph_acl_sec_ctx *as) > > +{ > > + return 0; > > +} > > + > > #endif /* CONFIG_FS_ENCRYPTION */ > > Seems there should at least be something that prevents you from creating a file > in an encrypted directory when !CONFIG_FS_ENCRYPTION. > > The other filesystems use fscrypt_prepare_new_inode() for this; it returns > EOPNOTSUPP when IS_ENCRYPTED(dir). > Once we have the MDS support done, we should be able to make it reject create requests from clients that don't support the new feature flag, but denying it on the client is more efficient. Fixed in my tree. Thanks! -- Jeff Layton