Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1664041rwb; Fri, 19 Aug 2022 07:26:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR4ObB0Jg8aW/P5sgww9a5Y114STxpptf/CqCxHKA0+HvFZkimAgHNPS2LKkpo60ohDvW6nf X-Received: by 2002:a05:6402:27cf:b0:43f:f6a:3286 with SMTP id c15-20020a05640227cf00b0043f0f6a3286mr6236804ede.1.1660919213608; Fri, 19 Aug 2022 07:26:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660919213; cv=none; d=google.com; s=arc-20160816; b=gU/fddQEtoCtceW+1WVgchZBq7oIsNUKsQ1r1EItPfCNTLkIRgqqc0/ATctuC/FG98 Wuzx/BMOqqpiG2e2bRMiI1FoThKXuGOH2zhOQYg2TgbrwUosd4xcqFi71a/fUbzutD3J Naq/kIp2J1HZbLaDWpXIJuJLVdvrWIJB6g8P5xaBNHfw8A6R/1nAb0RqxpzM+doSy2yn n/YI+po4Y+6BR5CHn0ZP3kNkAVaOVqKJRz9/aHH71EbnMgVgY8bbiSgnghuqgMb3+HCj rOoAY/CpmIGTP6DgRr3owiq3E1OVLPuZZ9qnL1BMLFFnP2e0zJemkQFlaG6bXwTZACqu aWXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=8zqquuEhRDjH7nVxfkiuZtn7Lef0I4tXNA1l6b9ya6o=; b=znXbH1dz8XTyGrPiXaEGuVtxWpwuZMUZChcRh0urivmK1mWCvsYmaaY1ZOkJspZN7K HvXOFhLTTuKK+ThHfpQqoMOZPaDVkE1NsSSU9VjN6Z7upDqSTsEw5eIycYaGURa7uWou VAE84lhUha+xSI9EVAiK94U2s1uc43WPHKav/ELCHCi2JXLRXwFj/Dtv8rIala3PpgNB 9JmmpV/zUoNSZ/0rSoEiByjqp2lO9SrUjYEsplPbqj1rcnKziqJpzdZ5CRp/ASpOfCMl 2uAdXiowSZ7CKOzWvsMND6dokSAfM5vtv9gkqqs0idOZocUkYJp0ovgHfHGgJsuCbJY6 KH5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@umich.edu header.s=google-2016-06-03 header.b=iLHo4LaY; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umich.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id au28-20020a170907093c00b0073045f4792dsi2777662ejc.491.2022.08.19.07.26.16; Fri, 19 Aug 2022 07:26:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-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=@umich.edu header.s=google-2016-06-03 header.b=iLHo4LaY; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umich.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348895AbiHSOXC (ORCPT + 99 others); Fri, 19 Aug 2022 10:23:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349063AbiHSOXA (ORCPT ); Fri, 19 Aug 2022 10:23:00 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4834B72AD; Fri, 19 Aug 2022 07:22:59 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id o22so5849453edc.10; Fri, 19 Aug 2022 07:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=8zqquuEhRDjH7nVxfkiuZtn7Lef0I4tXNA1l6b9ya6o=; b=iLHo4LaY1kzm0o7kBmnrS8yDYyw2qP/D+rp1lTFyInUum4NCRybh77J7clt7cjgusG nBl4FZ0p37ZWjsef9YjmMxlWN/TlPmRZT721R38ikRGJYd+0q2ovLnJONK9Xpi1i2k8l yMvlIBWLqUF40hz0wsB3glHxNDSKbgrnVYzWQ8rAYjkrcVBI5YH57v0Cp2rBBTm0u6K5 46QoSc/E9zRiALAFaK3V+vLrbkrz/F/55HqNN42G9u8h/pPA/NSal9O+G1oDpWL4oxyQ aQ7oHvESpDlk7Z6nKzyH2Z0na6NC/umcvc3U1PLobDqts0s3WD2jpo8dfZQZkNMx2FcU huNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=8zqquuEhRDjH7nVxfkiuZtn7Lef0I4tXNA1l6b9ya6o=; b=ToMGnCxkB9Cq911GqB4SkrEc//jPra5yPw1vsdofbyz1eerKHf8/HzmoRMPhcUEWAD Mzc2fsaPCJZXjjWliurex2KaJBM9ZNDO6GrxmrJfVkNNGvS6HSzEWsbBvH92DaMGEWVy X97/dO/sAxJH3usDRbplkKJSN6jq2aMMmPFt9anGTb8hZ6Ac7fA/dO2XUmmx4axNKWsM 1DzgBIx5bUGLaExmzn9o+X5RRx82X1npV6RxGPC0TDUj7RUffBDBzCU4hpze8f8EgpHp CpvC1bmCimc8lPkfKSp/BPUdHhZk+U15htat2bG/x7gFYivFiSVgJBhgOZxDVPaFfzsH fPuQ== X-Gm-Message-State: ACgBeo1ZG77lSzbcl6/p+CGInC1NxOCNALTTx2NCKaE+XEmW5frhVHY+ vQZVAFmSO+GWtIjxno6bYfo+UdDEHR/PZoFvm0k= X-Received: by 2002:a05:6402:40c2:b0:440:4ecd:f75f with SMTP id z2-20020a05640240c200b004404ecdf75fmr6219384edb.405.1660918978362; Fri, 19 Aug 2022 07:22:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olga Kornievskaia Date: Fri, 19 Aug 2022 10:22:46 -0400 Message-ID: Subject: Re: [RFC] problems with alloc_file_pseudo() use in __nfs42_ssc_open() To: Dai Ngo Cc: Al Viro , Amir Goldstein , linux-nfs , Olga Kornievskaia , linux-fsdevel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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-nfs@vger.kernel.org On Thu, Aug 18, 2022 at 10:52 PM wrote: > > > On 8/18/22 6:13 AM, Olga Kornievskaia wrote: > > On Thu, Aug 18, 2022 at 1:52 AM Al Viro wrote: > >> On Thu, Aug 18, 2022 at 08:19:54AM +0300, Amir Goldstein wrote: > >> > >>> NFS spec does not guarantee the safety of the server. > >>> It's like saying that the Law makes Crime impossible. > >>> The law needs to be enforced, so if server gets a request > >>> to COPY from/to an fhandle that resolves as a non-regular file > >>> (from a rogue or buggy NFS client) the server should return an > >>> error and not continue to alloc_file_pseudo(). > >> FWIW, my preference would be to have alloc_file_pseudo() reject > >> directory inodes if it ever gets such. > >> > >> I'm still not sure that my (and yours, apparently) interpretation > >> of what Olga said is correct, though. > > Would it be appropriate to do the following then: > > > > diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c > > index e88f6b18445e..112134b6438d 100644 > > --- a/fs/nfs/nfs4file.c > > +++ b/fs/nfs/nfs4file.c > > @@ -340,6 +340,11 @@ static struct file *__nfs42_ssc_open(struct > > vfsmount *ss_mnt, > > goto out; > > } > > > > + if (S_ISDIR(fattr->mode)) { > > + res = ERR_PTR(-EBADF); > > + goto out; > > + } > > + > > Can we also enhance nfsd4_do_async_copy to check for > -EBADF and returns nfserr_wrong_type? perhaps adding > an error mapping function to handle other errors also. On the server side, if the open fails that's already translated into the appropriate error -- err_off_load_denied. > > -Dai > > > res = ERR_PTR(-ENOMEM); > > len = strlen(SSC_READ_NAME_BODY) + 16; > > read_name = kzalloc(len, GFP_KERNEL); > > @@ -357,6 +362,7 @@ static struct file *__nfs42_ssc_open(struct > > vfsmount *ss_mnt, > > r_ino->i_fop); > > if (IS_ERR(filep)) { > > res = ERR_CAST(filep); > > + iput(r_ino); > > goto out_free_name; > > }