Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp3213435rwo; Fri, 4 Aug 2023 00:51:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF6WZ1IL1yGHgoUP6ARahrZ8kWzUtzHaAMEeootq7ng/afQfZ4n+FZKUROeVU3q9bMOWOz7 X-Received: by 2002:a05:6a00:a28:b0:687:5c3f:d834 with SMTP id p40-20020a056a000a2800b006875c3fd834mr1382059pfh.11.1691135493418; Fri, 04 Aug 2023 00:51:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691135493; cv=none; d=google.com; s=arc-20160816; b=A51FlWJdMuuJCHPZxlBWzXkNFFRaeqqHpzAyG7F1TXJpWYFUIEPuMP+2ZDu3noI19/ FUx7p+kYFvBTUUS0odhM5pwZpJS5SKGvvYXrgxY1kuz7sIBEKMdY5eNdsN/z2RgNoRzA F9nkx2mREDRKZC8Gc5wgY2pUo+Op0O2jZAFOAD8cIU65W5WUOWVx+A9KTjP/MT8+GCwK V7vO12wvb38QA0hAhu12M+LPu2zeeEX7aTyIBrbmMSDfJrNsac4VJLWOE8kGUUQbgyGi Tl6aBmn7cDV8yJ2M2FCs6SsCJYC7ZoriDL/6+UtjG9TuiWIlf0KAAsHyg3DJRHCSMfAE Zrtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4ehLogqpf8AbHxOn+oiX5uttkJ8cN5sGSHt2uLmpG5o=; fh=Jn0e+2S9VM6R/lNpVnmV1sO0K9VcnKvFJy5x6ylowTM=; b=0TzEHY49j3w6r2fAZaoeM7jcUbMAnlz6beOXqR8gHHZnoMRCO1b4I99ZxX3gjPZ0Fs DcnJYulULAlopXzM9QEKF14iggCsKavcJlIfJ7QboxfGYBF5NKmHHn3e1hojkJ+NrLNu PIoHkVfHeelLSUwVmh6e0oVrFyOT/kbf99PrMe6An80HeM6csv+miskQzyJV+NUHY4B2 b7kKDw7Gi6dOTfPAq/KXRvMzic9SLe5gsP2CYThzvQGYu27ey7UwXbXqXf9QIarKGAxf XjuP/+e6XpTbnjWoA4HHjG5qfy6ovI3kTw6XYZNuIyoQ1N3pmc9CvPWEwV4k2aAZnxOW +f1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=DrzISXyx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cb7-20020a056a00430700b00687427c1ac1si1335274pfb.25.2023.08.04.00.51.21; Fri, 04 Aug 2023 00:51:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=DrzISXyx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232784AbjHDGgV (ORCPT + 99 others); Fri, 4 Aug 2023 02:36:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232607AbjHDGgS (ORCPT ); Fri, 4 Aug 2023 02:36:18 -0400 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 774A24687 for ; Thu, 3 Aug 2023 23:36:04 -0700 (PDT) Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id DFDE6417B7 for ; Fri, 4 Aug 2023 06:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1691130961; bh=4ehLogqpf8AbHxOn+oiX5uttkJ8cN5sGSHt2uLmpG5o=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DrzISXyx0qaN2hESNY9ggL0wVbebMSatoXIL0MA2L5uwQEn9utsk2fik1Y+8ogXQx KJZyqBq0zx2g04dc72c/mqiZAPVNdKZsv2RU197Ry0g7ot3fjloWk4y4ekX0e72nNi phoNxTbR78ZVawBT7rjXNWPPZ+rEudIffQHxURJE/nw+11ACxAdfNORO+tomorr742 m5D3Rv8Xj+Ki2VB8neB6D3ayeLufN4ilwoA05vh+nBdAZ1zrvdu2rTWGt34Iby6koV HxuU5lWbfCijG16VWGjbaHKKmMoIbjjqr28jzjTrf/ZvdQQPHXhcrU7xWHwFtu0hey jJtSdztfnV49w== Received: by mail-yb1-f197.google.com with SMTP id 3f1490d57ef6-d10792c7582so1861210276.3 for ; Thu, 03 Aug 2023 23:36:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691130961; x=1691735761; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4ehLogqpf8AbHxOn+oiX5uttkJ8cN5sGSHt2uLmpG5o=; b=fQyG72wcB6MQbDDXz8pD3725GruONBPwDG3ItQqQyGQ21dDP0RCsZGbI7NNEoaJa61 jQcGpKtNapu9LJiFaSYSrHZn3t0QWvTVvPEjLogom1/16w38dCi38xNOmIRuGNK9ix5f +uBmGwxjQTOLdrswuE5Xrox0fPYQNaqXCCwYra5Ge2v6UsXaoBsdDm8zWzWMG8XfVilb XzUF8miRKkvk7hSFV9/Wa3n6/sSdvuDofv0xa5/q7qM7CrwY9+iKgtBMW5cAH6WnG3cJ +wRMhjIqloMX9r+ZYk0j8+u7pdao6kF0s49Kj3fgG/8UVx83RTHzupnPLkdOEYVnaPdA NSCQ== X-Gm-Message-State: AOJu0YztWymdvbWGoWuyL3kegLjVJvy0ceXCfeHS0CD/bVnJuAVsKFeX LKhzNgdtZWYEPiIbHEl0dLSdN7J8Ed9yKNX8v9IpIxFKi1N1cWX2dR64ntDbyY27Eh9X5DwAzEe IogiLrDkYdBolqULnDNxMuKEhBbWEDflzjG+THZFNg89srB529mXkKBYdkg== X-Received: by 2002:a25:2d0a:0:b0:d17:240c:2b40 with SMTP id t10-20020a252d0a000000b00d17240c2b40mr609948ybt.63.1691130960872; Thu, 03 Aug 2023 23:36:00 -0700 (PDT) X-Received: by 2002:a25:2d0a:0:b0:d17:240c:2b40 with SMTP id t10-20020a252d0a000000b00d17240c2b40mr609941ybt.63.1691130960637; Thu, 03 Aug 2023 23:36:00 -0700 (PDT) MIME-Version: 1.0 References: <20230803135955.230449-1-aleksandr.mikhalitsyn@canonical.com> <20230803135955.230449-4-aleksandr.mikhalitsyn@canonical.com> <71018b94-45a0-3404-d3d0-d9f808a72a00@redhat.com> <41ba61bf-3a45-cb20-1e4c-38dbd65bafa6@redhat.com> In-Reply-To: <41ba61bf-3a45-cb20-1e4c-38dbd65bafa6@redhat.com> From: Aleksandr Mikhalitsyn Date: Fri, 4 Aug 2023 08:35:49 +0200 Message-ID: Subject: Re: [PATCH v8 03/12] ceph: handle idmapped mounts in create_request_message() To: Xiubo Li Cc: brauner@kernel.org, stgraber@ubuntu.com, linux-fsdevel@vger.kernel.org, Jeff Layton , Ilya Dryomov , ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham 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, Aug 4, 2023 at 5:24=E2=80=AFAM Xiubo Li wrote: > > > On 8/4/23 10:26, Xiubo Li wrote: > > > > On 8/3/23 21:59, Alexander Mikhalitsyn wrote: > >> From: Christian Brauner > >> > >> Inode operations that create a new filesystem object such as ->mknod, > >> ->create, ->mkdir() and others don't take a {g,u}id argument explicitl= y. > >> Instead the caller's fs{g,u}id is used for the {g,u}id of the new > >> filesystem object. > >> > >> In order to ensure that the correct {g,u}id is used map the caller's > >> fs{g,u}id for creation requests. This doesn't require complex changes. > >> It suffices to pass in the relevant idmapping recorded in the request > >> message. If this request message was triggered from an inode operation > >> that creates filesystem objects it will have passed down the relevant > >> idmaping. If this is a request message that was triggered from an inod= e > >> operation that doens't need to take idmappings into account the initia= l > >> idmapping is passed down which is an identity mapping. > >> > >> This change uses a new cephfs protocol extension > >> CEPHFS_FEATURE_HAS_OWNER_UIDGID > >> which adds two new fields (owner_{u,g}id) to the request head structur= e. > >> So, we need to ensure that MDS supports it otherwise we need to fail > >> any IO that comes through an idmapped mount because we can't process i= t > >> in a proper way. MDS server without such an extension will use > >> caller_{u,g}id > >> fields to set a new inode owner UID/GID which is incorrect because > >> caller_{u,g}id > >> values are unmapped. At the same time we can't map these fields with a= n > >> idmapping as it can break UID/GID-based permission checks logic on the > >> MDS side. This problem was described with a lot of details at [1], [2]= . > >> > >> [1] > >> https://lore.kernel.org/lkml/CAEivzxfw1fHO2TFA4dx3u23ZKK6Q+EThfzuibrhA= 3RKM=3DZOYLg@mail.gmail.com/ > >> [2] > >> https://lore.kernel.org/all/20220104140414.155198-3-brauner@kernel.org= / > >> > >> https://github.com/ceph/ceph/pull/52575 > >> https://tracker.ceph.com/issues/62217 > >> > >> Cc: Xiubo Li > >> Cc: Jeff Layton > >> Cc: Ilya Dryomov > >> Cc: ceph-devel@vger.kernel.org > >> Co-Developed-by: Alexander Mikhalitsyn > >> > >> Signed-off-by: Christian Brauner > >> Signed-off-by: Alexander Mikhalitsyn > >> > >> --- > >> v7: > >> - reworked to use two new fields for owner UID/GID > >> (https://github.com/ceph/ceph/pull/52575) > >> v8: > >> - properly handled case when old MDS used with new kernel client > >> --- > >> fs/ceph/mds_client.c | 46 +++++++++++++++++++++++++++++++++-= -- > >> fs/ceph/mds_client.h | 5 +++- > >> include/linux/ceph/ceph_fs.h | 4 +++- > >> 3 files changed, 50 insertions(+), 5 deletions(-) > >> > >> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c > >> index 8829f55103da..7d3106d3b726 100644 > >> --- a/fs/ceph/mds_client.c > >> +++ b/fs/ceph/mds_client.c > >> @@ -2902,6 +2902,17 @@ static void encode_mclientrequest_tail(void > >> **p, const struct ceph_mds_request * > >> } > >> } > >> +static inline u16 mds_supported_head_version(struct > >> ceph_mds_session *session) > >> +{ > >> + if (!test_bit(CEPHFS_FEATURE_32BITS_RETRY_FWD, > >> &session->s_features)) > >> + return 1; > >> + > >> + if (!test_bit(CEPHFS_FEATURE_HAS_OWNER_UIDGID, > >> &session->s_features)) > >> + return 2; > >> + > >> + return CEPH_MDS_REQUEST_HEAD_VERSION; > >> +} > >> + > >> static struct ceph_mds_request_head_legacy * > >> find_legacy_request_head(void *p, u64 features) > >> { > >> @@ -2923,6 +2934,7 @@ static struct ceph_msg > >> *create_request_message(struct ceph_mds_session *session, > >> { > >> int mds =3D session->s_mds; > >> struct ceph_mds_client *mdsc =3D session->s_mdsc; > >> + struct ceph_client *cl =3D mdsc->fsc->client; > >> struct ceph_msg *msg; > >> struct ceph_mds_request_head_legacy *lhead; > >> const char *path1 =3D NULL; > >> @@ -2936,7 +2948,7 @@ static struct ceph_msg > >> *create_request_message(struct ceph_mds_session *session, > >> void *p, *end; > >> int ret; > >> bool legacy =3D !(session->s_con.peer_features & > >> CEPH_FEATURE_FS_BTIME); > >> - bool old_version =3D !test_bit(CEPHFS_FEATURE_32BITS_RETRY_FWD, > >> &session->s_features); > >> + u16 request_head_version =3D mds_supported_head_version(session); > >> ret =3D set_request_path_attr(mdsc, req->r_inode, req->r_dentr= y, > >> req->r_parent, req->r_path1, req->r_ino1.ino, > >> @@ -2977,8 +2989,10 @@ static struct ceph_msg > >> *create_request_message(struct ceph_mds_session *session, > >> */ > >> if (legacy) > >> len =3D sizeof(struct ceph_mds_request_head_legacy); > >> - else if (old_version) > >> + else if (request_head_version =3D=3D 1) > >> len =3D sizeof(struct ceph_mds_request_head_old); > >> + else if (request_head_version =3D=3D 2) > >> + len =3D offsetofend(struct ceph_mds_request_head, ext_num_fwd= ); > >> else > >> len =3D sizeof(struct ceph_mds_request_head); > > > > This is not what we suppose to. If we do this again and again when > > adding new members it will make the code very complicated to maintain. > > > > Once the CEPHFS_FEATURE_32BITS_RETRY_FWD has been supported the ceph > > should correctly decode it and if CEPHFS_FEATURE_HAS_OWNER_UIDGID is > > not supported the decoder should skip it directly. > > > > Is the MDS side buggy ? Why you last version didn't work ? > > > > I think the ceph side is buggy. Possibly we should add one new `length` > member in struct `struct ceph_mds_request_head` and just skip the extra > bytes when decoding it. Hm, I think I found something suspicious. In cephfs code we have many places that call the DECODE_FINISH macro, but in our decoder we don't have it. From documentation it follows that DECODE_FINISH purpose is precisely about this problem. What do you think? > > Could you fix it together with your ceph PR ? > > Thanks > > - Xiubo > > > > Thanks > > > > - Xiubo > > > >> @@ -3028,6 +3042,16 @@ static struct ceph_msg > >> *create_request_message(struct ceph_mds_session *session, > >> lhead =3D find_legacy_request_head(msg->front.iov_base, > >> session->s_con.peer_features); > >> + if ((req->r_mnt_idmap !=3D &nop_mnt_idmap) && > >> + !test_bit(CEPHFS_FEATURE_HAS_OWNER_UIDGID, > >> &session->s_features)) { > >> + pr_err_ratelimited_client(cl, > >> + "idmapped mount is used and > >> CEPHFS_FEATURE_HAS_OWNER_UIDGID" > >> + " is not supported by MDS. Fail request with -EIO.\n"); > >> + > >> + ret =3D -EIO; > >> + goto out_err; > >> + } > >> + > >> /* > >> * The ceph_mds_request_head_legacy didn't contain a version > >> field, and > >> * one was added when we moved the message version from 3->4. > >> @@ -3035,17 +3059,33 @@ static struct ceph_msg > >> *create_request_message(struct ceph_mds_session *session, > >> if (legacy) { > >> msg->hdr.version =3D cpu_to_le16(3); > >> p =3D msg->front.iov_base + sizeof(*lhead); > >> - } else if (old_version) { > >> + } else if (request_head_version =3D=3D 1) { > >> struct ceph_mds_request_head_old *ohead =3D msg->front.iov_b= ase; > >> msg->hdr.version =3D cpu_to_le16(4); > >> ohead->version =3D cpu_to_le16(1); > >> p =3D msg->front.iov_base + sizeof(*ohead); > >> + } else if (request_head_version =3D=3D 2) { > >> + struct ceph_mds_request_head *nhead =3D msg->front.iov_base; > >> + > >> + msg->hdr.version =3D cpu_to_le16(6); > >> + nhead->version =3D cpu_to_le16(2); > >> + > >> + p =3D msg->front.iov_base + offsetofend(struct > >> ceph_mds_request_head, ext_num_fwd); > >> } else { > >> struct ceph_mds_request_head *nhead =3D msg->front.iov_base; > >> + kuid_t owner_fsuid; > >> + kgid_t owner_fsgid; > >> msg->hdr.version =3D cpu_to_le16(6); > >> nhead->version =3D cpu_to_le16(CEPH_MDS_REQUEST_HEAD_VERSION= ); > >> + > >> + owner_fsuid =3D from_vfsuid(req->r_mnt_idmap, &init_user_ns, > >> + VFSUIDT_INIT(req->r_cred->fsuid)); > >> + owner_fsgid =3D from_vfsgid(req->r_mnt_idmap, &init_user_ns, > >> + VFSGIDT_INIT(req->r_cred->fsgid)); > >> + nhead->owner_uid =3D cpu_to_le32(from_kuid(&init_user_ns, > >> owner_fsuid)); > >> + nhead->owner_gid =3D cpu_to_le32(from_kgid(&init_user_ns, > >> owner_fsgid)); > >> p =3D msg->front.iov_base + sizeof(*nhead); > >> } > >> diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h > >> index e3bbf3ba8ee8..8f683e8203bd 100644 > >> --- a/fs/ceph/mds_client.h > >> +++ b/fs/ceph/mds_client.h > >> @@ -33,8 +33,10 @@ enum ceph_feature_type { > >> CEPHFS_FEATURE_NOTIFY_SESSION_STATE, > >> CEPHFS_FEATURE_OP_GETVXATTR, > >> CEPHFS_FEATURE_32BITS_RETRY_FWD, > >> + CEPHFS_FEATURE_NEW_SNAPREALM_INFO, > >> + CEPHFS_FEATURE_HAS_OWNER_UIDGID, > >> - CEPHFS_FEATURE_MAX =3D CEPHFS_FEATURE_32BITS_RETRY_FWD, > >> + CEPHFS_FEATURE_MAX =3D CEPHFS_FEATURE_HAS_OWNER_UIDGID, > >> }; > >> #define CEPHFS_FEATURES_CLIENT_SUPPORTED { \ > >> @@ -49,6 +51,7 @@ enum ceph_feature_type { > >> CEPHFS_FEATURE_NOTIFY_SESSION_STATE, \ > >> CEPHFS_FEATURE_OP_GETVXATTR, \ > >> CEPHFS_FEATURE_32BITS_RETRY_FWD, \ > >> + CEPHFS_FEATURE_HAS_OWNER_UIDGID, \ > >> } > >> /* > >> diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs= .h > >> index 5f2301ee88bc..6eb83a51341c 100644 > >> --- a/include/linux/ceph/ceph_fs.h > >> +++ b/include/linux/ceph/ceph_fs.h > >> @@ -499,7 +499,7 @@ struct ceph_mds_request_head_legacy { > >> union ceph_mds_request_args args; > >> } __attribute__ ((packed)); > >> -#define CEPH_MDS_REQUEST_HEAD_VERSION 2 > >> +#define CEPH_MDS_REQUEST_HEAD_VERSION 3 > >> struct ceph_mds_request_head_old { > >> __le16 version; /* struct version */ > >> @@ -530,6 +530,8 @@ struct ceph_mds_request_head { > >> __le32 ext_num_retry; /* new count retry attempts */ > >> __le32 ext_num_fwd; /* new count fwd attempts */ > >> + > >> + __le32 owner_uid, owner_gid; /* used for OPs which create > >> inodes */ > >> } __attribute__ ((packed)); > >> /* cap/lease release record */ >