Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1794481rwi; Thu, 20 Oct 2022 17:55:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6dXeCQTkhxIOFX7Z80uwMbGNT0OlZ7sF/WWJjs3nwfnYos/UHzEfmhL1Nl1Aq2SvsW+Tyv X-Received: by 2002:aa7:d7c5:0:b0:459:fad8:fd2 with SMTP id e5-20020aa7d7c5000000b00459fad80fd2mr14972982eds.336.1666313703362; Thu, 20 Oct 2022 17:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666313703; cv=none; d=google.com; s=arc-20160816; b=Pij22Op4q5QoFuwH5NNpGGUdicBU/fmk6dhvuGKjPXZuPrVYyar+c5s4IJlfTypPix Ay30Ivn2ZWdkcaoZGZlwSfG9m6hDL1HEdlHq+sp7t+1TnMaUL4uAbjXMAeC+r3KriV/R RGtx4J641QsgpqOsI1Wugn85WCE6Jt11kzddVUWsYT0hnGhaNVwX6hg8rVz4oiEImbLT yevS3AKECMK4y7/FFgMGuauOADqD1JtgtfJbUQkw689v9822jMjI/4moooVOA+ajIFD2 Ux9ghPvETQrGanoImRnTKoiCQrHTbqz8cFNPsDin8lfrJ4KECNhxrOBQtFcLeKDfTWe6 CVsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=7i3Q+7eBNqgwe8myvD4IZGSdBbgBR1napgG+yyVui4s=; b=WAwaXnUoVo35ySHd0u9BLk5nQ8JxSawHJUs6p2lJx4TxT3xnuVw9v1hjS0z7Jcv3VQ /VOlTIB32u91DLPxyqw3MB0DY5NuQV33j3W4t7o9kkrdrRjWe0L3afu8nzrhgqPP7f3f /4NeT+ZrTfuA6U/ZPg4TYe8jlw3N5fd7t8i6kEFhvT9okJVx4xxn8BmO4wROWmZTcYo4 0XiBCWiMi+LR1f56ldZSXT6W2uX6gZ6tmkABD3D5zfQtzN9OKexu6ukRFwC4h/FC5riv VTM8RDIHod4bPSeS1jhBBJSTHlBVVWrxNJSMIbu3IG9KQ1PnT/nKY+xjk1n0tQs/6Pn8 ejsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="M/nFneel"; 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 o5-20020a1709061d4500b0078db3f08a6bsi14611357ejh.720.2022.10.20.17.54.37; Thu, 20 Oct 2022 17:55:03 -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="M/nFneel"; 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 S229909AbiJUArp (ORCPT + 99 others); Thu, 20 Oct 2022 20:47:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229908AbiJUArT (ORCPT ); Thu, 20 Oct 2022 20:47:19 -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 A990022BC91 for ; Thu, 20 Oct 2022 17:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666313234; 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=7i3Q+7eBNqgwe8myvD4IZGSdBbgBR1napgG+yyVui4s=; b=M/nFneelC/MxWrBX8RTnCpZ/ABww8wdqRiuVgLC6ahcfa+Gvk0eVR2G4Pp8d37LOmR3lEe 94+Q5TjoeUDpRA7hXjEOC7u+JnrBDmYv45ApI9YifP7eAzqzleQcwDCtwZHim8n0kIH+9U Sa7PExplKSJydlb12JtDAtq0a6RZX8w= Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-335-2xnlZa64P5SgE6k8EN-64Q-1; Thu, 20 Oct 2022 20:47:13 -0400 X-MC-Unique: 2xnlZa64P5SgE6k8EN-64Q-1 Received: by mail-pl1-f200.google.com with SMTP id u8-20020a170902e5c800b00185483ee4f5so584084plf.10 for ; Thu, 20 Oct 2022 17:47:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7i3Q+7eBNqgwe8myvD4IZGSdBbgBR1napgG+yyVui4s=; b=q7WKCRklRThmSUwV8gGIMhXBLGuAaz3F2Jspw6vQNl7/Lauc/sncjIZuT2xBcx0MrU 3Yf9sPPT9T1YIUT4O0iZ4PiuaX5ckopBAOHnk/A5IZUlSRszVZ1h1F8wQezPQsf8uPVb T4SsWSdVhyLYBOMPn5wq+4xjzaEi57slLnY1u3fvB/MAq+07G+4K7UAYwX+NJRuqcQPi pkaOwAL1gRgCZFEXJs9lpF+KaUHlrPEri1jUkhA5J7MHgrWzrksNzA6YWHXc8iQxjp2j cP0J0sNqZVvu3batZrlGYWIFN1x1xTz+6ZEUTssgH6z8gODJHiNy2ykGHMpVK69ja6kq 4nmg== X-Gm-Message-State: ACrzQf0MhuFOqeLh52/TQRKdjV/LIBo6a78cPiAQ8UJGAf9SOPnvlopm sK1Q0pNeMjEtY3/6PXBrcj9FuMLl+my0IPv5ta7g90C3BESVIKBALrL81x1Yi/qcR66OKcFmDr/ KxhpMxbMlI2CwMGvH7JV0RePPPiagCEVMtykdDjLZdfnn4ytsVU7mgRHZLsJZf8Wrpim6KdCMsQ == X-Received: by 2002:a63:1508:0:b0:438:eb90:52d1 with SMTP id v8-20020a631508000000b00438eb9052d1mr14302563pgl.252.1666313232338; Thu, 20 Oct 2022 17:47:12 -0700 (PDT) X-Received: by 2002:a63:1508:0:b0:438:eb90:52d1 with SMTP id v8-20020a631508000000b00438eb9052d1mr14302539pgl.252.1666313232011; Thu, 20 Oct 2022 17:47:12 -0700 (PDT) Received: from [10.72.12.79] ([43.228.180.230]) by smtp.gmail.com with ESMTPSA id n11-20020a170903404b00b0017849a2b56asm3547414pla.46.2022.10.20.17.47.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Oct 2022 17:47:11 -0700 (PDT) Subject: Re: [PATCH] fs/ceph/super: add mount options "snapdir{mode,uid,gid}" To: Jeff Layton , Max Kellermann Cc: idryomov@gmail.com, ceph-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220927120857.639461-1-max.kellermann@ionos.com> <88f8941f-82bf-5152-b49a-56cb2e465abb@redhat.com> <75e7f676-8c85-af0a-97b2-43664f60c811@redhat.com> <7e28f7d1-cfd5-642a-dd4e-ab521885187c@redhat.com> <8ef79208adc82b546cc4c2ba20b5c6ddbc3a2732.camel@kernel.org> From: Xiubo Li Message-ID: Date: Fri, 21 Oct 2022 08:47:04 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <8ef79208adc82b546cc4c2ba20b5c6ddbc3a2732.camel@kernel.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-2.4 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_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, 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 20/10/2022 18:13, Jeff Layton wrote: > On Thu, 2022-10-20 at 09:29 +0800, Xiubo Li wrote: [...] >>> I tend to agree with Max here. The .snap dir is a client-side fiction, >>> so trying to do something on the MDS to govern its use seems a bit odd. >>> cephx is really about authenticating clients. I know we do things like >>> enforce root squashing on the MDS, but this is a little different. >>> >>> Now, all of that said, snapshot handling is an area where I'm just not >>> that knowledgeable. Feel free to ignore my opinion here as uninformed. >> I am thinking currently the cephfs have the same issue we discussed >> here. Because the cephfs is saving the UID/GID number in the CInode >> metedata. While when there have multiple clients are sharing the same >> cephfs, so in different client nodes another user could cross access a >> specified user's files. For example: >> >> In client nodeA: >> >> user1's UID is 123, user2's UID is 321. >> >> In client nodeB: >> >> user1's UID is 321, user2's UID is 123. >> >> And if user1 create a fileA in the client nodeA, then user2 could access >> it from client nodeB. >> >> Doesn't this also sound more like a client-side fiction ? >> > idmapping is a difficult issue and not at all confined to CephFS. NFSv4 > has a whole upcall facility for mapping IDs, for instance. The MDS has > no way to know that 123 and 321 are the same user on different machines. > That sort of mapping must be set up by the administrator. > > The real question is: Does it make sense for the MDS to use directory > permissions to enforce access on something that isn't really a > directory? > > My "gut feeling" here is that the MDS ought to be in charge of governing > which _clients_ are allowed to make snapshots, but it's up to the client > to determine which _users_ are allowed to create them. With that concept > in mind, Max's proposal makes some sense. > > Snapshots are not part of POSIX, and the ".snap" directory interface was > copied from Netapp (AFAICT). Maybe CephFS ought to enforce permissions > on snapshots the same way Netapps do? I don't know exactly how it works > there, so some research may be required. > > I found this article but it's behind a paywall: > > https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS_7_Mode/How_to_control_access_to_a_Snapshot_directory > Yeah, these days I thought about this more. I will review this patch. BTW, as we discussed in IRC to switch this to module parameters instead. Then how about when the mounts are in different namespace groups, such as the containers ? This couldn't be control that precise, maybe we will hit the same idmapping issue as I mentioned above ? So maybe the mount option approach is the best choice here as Max does ? - Xiubo