Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp2867528rwb; Mon, 7 Aug 2023 05:01:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGsTxOMOnyvB2khR4ARKsDVRMYrH7rOZe2HI6YxWaHbz1t16UiVWBrW+c0a+p4P/Zibo1G+ X-Received: by 2002:a17:902:ab5c:b0:1bc:2bd:8520 with SMTP id ij28-20020a170902ab5c00b001bc02bd8520mr9197367plb.6.1691409719172; Mon, 07 Aug 2023 05:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691409719; cv=none; d=google.com; s=arc-20160816; b=cClbXYKrNZ8+WTK0RKkK5Iu/XUrxF8kjQDTSTM2L2vt1+w2MUtRDJkpfrRqdlq2KHU e3bjtNh12z5OeozRWieESQDRkAW8ITTGQNUXzzqAwq3ZZ5OWv6AbFQJVQ7rLRlAEtprC 3TeV3acycSsww7pejMXkmsoFqM7JKpDM4KBow+IByUe2119fArxAwjLURaAk9LW07nfX FS1RuLNmyTp3MyRrjKPTPwzhVilna0MvUzngo4bjSWjDy4ilCkWA7md1lohU5QU8Sx62 AA9oB8/7AggqWbiexbdKjHjOuU/t75MdixoVu0qkv0IK5lT+J1Bdu9NA02q5+DSfuUJX ZppA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=XN5gC0ZQhXU2kLFdzGcj+W8wiDigmtGB2Pp+bBDFoSU=; fh=qxh+wIqLlbHQVEewY25bM7+8dGrpmnwqIA4sVyewhK4=; b=xLOXHzdYOWdO8wo6YJJoyQWxB3PeG6+bppN7cZZIeSZnqa36H+D8u8LMlb4L+sT4VL E3P/dToB8VGGQfrAgOL0SkiWJ5Iv6RQqvrM0OLMae+NoP4Nzu5Ee2OjTmzJSd74OefrD JlD+V1h2q4RDqv4HLFpAJOOtcNnVu/NeFETB0dUqVUvebpdRv94oxSeEoqjkgj91rQlK 6vgdoUv3SH1/8cHJQXwTAwGkTtsjQdVwnRT3ZlZF+AHlFpbvIBuIDU5nCBbVoAaM+mqm ChM8ErHgD/IDjS0TBoVuJZQVPnJE8b3TS9SudumxSOKHwRbl5eylvns940+NMOyao6nG 0zBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IbPXGQaR; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d10-20020a170903208a00b001b8b3f21a18si3054350plc.637.2023.08.07.05.01.30; Mon, 07 Aug 2023 05:01:59 -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=@redhat.com header.s=mimecast20190719 header.b=IbPXGQaR; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231678AbjHGK3f (ORCPT + 99 others); Mon, 7 Aug 2023 06:29:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231634AbjHGK3a (ORCPT ); Mon, 7 Aug 2023 06:29:30 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ADB21703 for ; Mon, 7 Aug 2023 03:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691404123; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XN5gC0ZQhXU2kLFdzGcj+W8wiDigmtGB2Pp+bBDFoSU=; b=IbPXGQaRk3R24zeDqbVpBvBMxgLdmFNhZkEikNiNQXEB8DkJVR4Z0bwEQntjBLoPsrdum2 kgFHEjr9W4RWyTuQq3JoTdJWnPkRNv4pXK1pclRkofqveDFgYwZQ03ST933qLOnKvQBwl1 3rGSDomu786rQHq7BvC6VmlAAqDHsdM= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-365-erb4yeqLMDGm0UVaF5xKbQ-1; Mon, 07 Aug 2023 06:28:42 -0400 X-MC-Unique: erb4yeqLMDGm0UVaF5xKbQ-1 Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-56438e966baso2817938a12.2 for ; Mon, 07 Aug 2023 03:28:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691404121; x=1692008921; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XN5gC0ZQhXU2kLFdzGcj+W8wiDigmtGB2Pp+bBDFoSU=; b=Dp7SLcKK2eIKuF342iciyeHX2V6m7QrXfk+xf3rs0b+rBXojhBA0djTvmYj9mzLfw4 8+M5s5TjfX4ZlI7rFQRL3B2yxTtMwvK3+d29/3+bZj+0Ay9aCLvlnKYB2IWxFEbskEA7 gUl7+WluPJ2IxMu2CKz4Ul9Nx4NK++DMe/vApqlI9qrsqATKFbVnGJLgRt3AhKtOjTQN g3bZOHmys6Aypj4Y5iIgXkN5xdaFAlfaPdzJ8PZxuaaN+YZ8nq6PowYVt3gwWSMAfXXb /3MX0g81q0GK24kbU7d9sYOZvqiCK+Pd8u6IuRrFFHZWl0dH+abM7VuwtEbltQnxaX9E rR6A== X-Gm-Message-State: AOJu0YyJvhmKkfEjZJm6gG78M5EavD4BQhELcyZkpvgUJ75OsagqpFdm iGb95BuxBuUEn2fQUKJfO1ZW7ELPpkRDZ+hsYWFIJDdSQLokBzeDeDkpKwbxtCqsQG6NJXurKza 7A5Y6b0ozdypVo/Dq7B+eR/7rEqoRhW/VJUxt4Q== X-Received: by 2002:a05:6a20:440f:b0:13e:6447:ce45 with SMTP id ce15-20020a056a20440f00b0013e6447ce45mr11316164pzb.43.1691404121363; Mon, 07 Aug 2023 03:28:41 -0700 (PDT) X-Received: by 2002:a05:6a20:440f:b0:13e:6447:ce45 with SMTP id ce15-20020a056a20440f00b0013e6447ce45mr11316143pzb.43.1691404120950; Mon, 07 Aug 2023 03:28:40 -0700 (PDT) Received: from [10.72.112.77] ([43.228.180.230]) by smtp.gmail.com with ESMTPSA id b14-20020aa7870e000000b00687790191a2sm5850320pfo.58.2023.08.07.03.28.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Aug 2023 03:28:40 -0700 (PDT) Message-ID: Date: Mon, 7 Aug 2023 18:28:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v9 03/12] ceph: handle idmapped mounts in create_request_message() Content-Language: en-US To: Aleksandr Mikhalitsyn 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 References: <20230804084858.126104-1-aleksandr.mikhalitsyn@canonical.com> <20230804084858.126104-4-aleksandr.mikhalitsyn@canonical.com> <8446e5c9-7dd7-a1e9-e262-13811ee9e640@redhat.com> From: Xiubo Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE 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 8/7/23 14:51, Aleksandr Mikhalitsyn wrote: > On Mon, Aug 7, 2023 at 3:25 AM Xiubo Li wrote: >> >> On 8/4/23 16:48, 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 explicitly. >>> 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 inode >>> operation that doens't need to take idmappings into account the initial >>> 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 structure. >>> 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 it >>> 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 an >>> 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+EThfzuibrhA3RKM=ZOYLg@mail.gmail.com/ >>> [2] https://lore.kernel.org/all/20220104140414.155198-3-brauner@kernel.org/ >>> >>> Link: https://github.com/ceph/ceph/pull/52575 >>> Link: 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 | 47 +++++++++++++++++++++++++++++++++--- >>> fs/ceph/mds_client.h | 5 +++- >>> include/linux/ceph/ceph_fs.h | 5 +++- >>> 3 files changed, 52 insertions(+), 5 deletions(-) >>> >>> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c >>> index 8829f55103da..41e4bf3811c4 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 = session->s_mds; >>> struct ceph_mds_client *mdsc = session->s_mdsc; >>> + struct ceph_client *cl = mdsc->fsc->client; >>> struct ceph_msg *msg; >>> struct ceph_mds_request_head_legacy *lhead; >>> const char *path1 = NULL; >>> @@ -2936,7 +2948,7 @@ static struct ceph_msg *create_request_message(struct ceph_mds_session *session, >>> void *p, *end; >>> int ret; >>> bool legacy = !(session->s_con.peer_features & CEPH_FEATURE_FS_BTIME); >>> - bool old_version = !test_bit(CEPHFS_FEATURE_32BITS_RETRY_FWD, &session->s_features); >>> + u16 request_head_version = mds_supported_head_version(session); >>> >>> ret = set_request_path_attr(mdsc, req->r_inode, req->r_dentry, >>> 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 = sizeof(struct ceph_mds_request_head_legacy); >>> - else if (old_version) >>> + else if (request_head_version == 1) >>> len = sizeof(struct ceph_mds_request_head_old); >>> + else if (request_head_version == 2) >>> + len = offsetofend(struct ceph_mds_request_head, ext_num_fwd); >>> else >>> len = sizeof(struct ceph_mds_request_head); >>> >>> @@ -3028,6 +3042,16 @@ static struct ceph_msg *create_request_message(struct ceph_mds_session *session, >>> lhead = find_legacy_request_head(msg->front.iov_base, >>> session->s_con.peer_features); >>> >>> + if ((req->r_mnt_idmap != &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 = -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,34 @@ static struct ceph_msg *create_request_message(struct ceph_mds_session *session, >>> if (legacy) { >>> msg->hdr.version = cpu_to_le16(3); >>> p = msg->front.iov_base + sizeof(*lhead); >>> - } else if (old_version) { >>> + } else if (request_head_version == 1) { >>> struct ceph_mds_request_head_old *ohead = msg->front.iov_base; >>> >>> msg->hdr.version = cpu_to_le16(4); >>> ohead->version = cpu_to_le16(1); >>> p = msg->front.iov_base + sizeof(*ohead); >>> + } else if (request_head_version == 2) { >>> + struct ceph_mds_request_head *nhead = msg->front.iov_base; >>> + >>> + msg->hdr.version = cpu_to_le16(6); >>> + nhead->version = cpu_to_le16(2); >>> + >>> + p = msg->front.iov_base + offsetofend(struct ceph_mds_request_head, ext_num_fwd); >>> } else { >>> struct ceph_mds_request_head *nhead = msg->front.iov_base; >>> + kuid_t owner_fsuid; >>> + kgid_t owner_fsgid; >>> >>> msg->hdr.version = cpu_to_le16(6); >>> nhead->version = cpu_to_le16(CEPH_MDS_REQUEST_HEAD_VERSION); >>> + nhead->struct_len = sizeof(struct ceph_mds_request_head); >>> + >>> + owner_fsuid = from_vfsuid(req->r_mnt_idmap, &init_user_ns, >>> + VFSUIDT_INIT(req->r_cred->fsuid)); >>> + owner_fsgid = from_vfsgid(req->r_mnt_idmap, &init_user_ns, >>> + VFSGIDT_INIT(req->r_cred->fsgid)); >>> + nhead->owner_uid = cpu_to_le32(from_kuid(&init_user_ns, owner_fsuid)); >>> + nhead->owner_gid = cpu_to_le32(from_kgid(&init_user_ns, owner_fsgid)); >>> p = 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 = CEPHFS_FEATURE_32BITS_RETRY_FWD, >>> + CEPHFS_FEATURE_MAX = 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..b91699b08f26 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,9 @@ struct ceph_mds_request_head { >>> >>> __le32 ext_num_retry; /* new count retry attempts */ >>> __le32 ext_num_fwd; /* new count fwd attempts */ >>> + >>> + __le32 struct_len; /* to store size of struct ceph_mds_request_head */ >>> + __le32 owner_uid, owner_gid; /* used for OPs which create inodes */ >> Let's also initialize them to -1 for all the other requests as we do in >> your PR. > They are always initialized already. As you can see from the code we > don't have any extra conditions > on filling these fields. We always fill them with an appropriate > UID/GID. If mount is not idmapped then it's just == caller_uid/gid, > if mount idmapped then it's idmapped caller_uid/gid. Then in kclient all the request will always initialized the 'owner_{uid/gid}' with 'caller_{uid/gid}'. While in userspace libcephfs it will only set them for 'create/mknod/mkdir/symlink` instead. I'd prefer to make them consistent, which is what I am still focusing on, to make them easier to read and comparing when troubles hooting. Thanks - Xiubo > Kind regards, > Alex > >> Thanks >> >> - Xiubo >> >> >> >>> } __attribute__ ((packed)); >>> >>> /* cap/lease release record */