Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp446167pxk; Wed, 23 Sep 2020 07:16:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvuxRdTh3hn/CmUZ3s6JjYj+Y8WCzUfm+wQb/lWRt/EvE7ichO4LFDhkUC3XxOKIAoQuyJ X-Received: by 2002:a17:906:9346:: with SMTP id p6mr10093003ejw.305.1600870564062; Wed, 23 Sep 2020 07:16:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600870564; cv=none; d=google.com; s=arc-20160816; b=LldsV6ZU/oJV4b2bydVolLPxiwGGJ5nHsGZJkHtVHfjJLkzi39iHuTTKZKr6Z6EEAN OhzWydmlFLYiH/I82y5ulPOK2zbETIXnOoz87xomxXWkw7IMKWMNXzhPufqHaQx+tVNm Lgk20SbCvPCiXJJMaH8v4hNuliejNx2XQEVr4RcSg87yztwWZjp4YkOSTIUjMZB4GCoN 6Z9oNVtBBhS2IXIUTFaF1EZ2Mppdb9q3RDUOWh78TMT5F7xLcVzdGHR/0up74vxKUIm7 5CYrrCx+ha5EanKibKUijc/1qlXB8HB1vEvQ3HvY+zzOAmT9uf8813l9QvMqmKBqaaxE DGVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=KTWSD1jYbYVvn0GmuMYFY+oRCeXR3jWpoma4G+RXx6U=; b=rF9/hQJ5+jeqZn1JDjiGs52Y6uoCCRVzj/bPl05Yw+36NXUowS8ZdKot0KG3oMVqpg am2IGLlB8rk4/gXsoxxRsQMkTgtZtYWdnzLYdxZNdsu2qGS8kNW6chl7TuWzv42N+JNh HPe8lLk5Yd0qVHrart65t3sps6Ae5yh9j6/4sW18HB+QOC4RUCi7Y20pkY78Gdj3xA9n Fye64BXmReKL7zpmll9TboNpxy8aWtxKeEBlOs2LuyCigtz6W9691eYiGOIrY1OQX+HB Lm0BiAbaZY5keyZ+yetLuejyOD6deg5RQlEvc7LediLu6WQYquzs1ZvVVlmQSdER6IO2 17oA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z12si14018770edm.560.2020.09.23.07.15.36; Wed, 23 Sep 2020 07:16:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726752AbgIWOMM (ORCPT + 99 others); Wed, 23 Sep 2020 10:12:12 -0400 Received: from foss.arm.com ([217.140.110.172]:47104 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbgIWOML (ORCPT ); Wed, 23 Sep 2020 10:12:11 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 798ED1396; Wed, 23 Sep 2020 07:12:10 -0700 (PDT) Received: from entos-thunderx2-desktop.shanghai.arm.com (entos-thunderx2-desktop.shanghai.arm.com [10.169.212.215]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 892233F73B; Wed, 23 Sep 2020 07:12:07 -0700 (PDT) From: Jianyong Wu To: ericvh@gmail.com, lucho@ionkov.net, asmadeus@codewreck.org, qemu_oss@crudebyte.com Cc: groug@kaod.org, v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, justin.he@arm.com, jianyong.wu@arm.com Subject: [PATCH v2 3/4] fs/9p: search open fids first Date: Wed, 23 Sep 2020 22:11:45 +0800 Message-Id: <20200923141146.90046-4-jianyong.wu@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200923141146.90046-1-jianyong.wu@arm.com> References: <20200923141146.90046-1-jianyong.wu@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Greg Kurz A previous patch fixed the "create-unlink-getattr" idiom: if getattr is called on an unlinked file, we try to find an open fid attached to the corresponding inode. We have a similar issue with file permissions and setattr: open("./test.txt", O_RDWR|O_CREAT, 0666) = 4 chmod("./test.txt", 0) = 0 truncate("./test.txt", 0) = -1 EACCES (Permission denied) ftruncate(4, 0) = -1 EACCES (Permission denied) The failure is expected with truncate() but not with ftruncate(). This happens because the lookup code does find a matching fid in the dentry list. Unfortunately, this is not an open fid and the server will be forced to rely on the path name, rather than on an open file descriptor. This is the case in QEMU: the setattr operation will use truncate() and fail because of bad write permissions. This patch changes the logic in the lookup code, so that we consider open fids first. It gives a chance to the server to match this open fid to an open file descriptor and use ftruncate() instead of truncate(). This does not change the current behaviour for truncate() and other path name based syscalls, since file permissions are checked earlier in the VFS layer. With this patch, we get: open("./test.txt", O_RDWR|O_CREAT, 0666) = 4 chmod("./test.txt", 0) = 0 truncate("./test.txt", 0) = -1 EACCES (Permission denied) ftruncate(4, 0) = 0 Signed-off-by: Greg Kurz Signed-off-by: Jianyong Wu --- fs/9p/fid.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/9p/fid.c b/fs/9p/fid.c index d11dd430590d..0b23b0fe6c51 100644 --- a/fs/9p/fid.c +++ b/fs/9p/fid.c @@ -95,8 +95,12 @@ static struct p9_fid *v9fs_fid_find(struct dentry *dentry, kuid_t uid, int any) dentry, dentry, from_kuid(&init_user_ns, uid), any); ret = NULL; + + if (d_inode(dentry)) + ret = v9fs_fid_find_inode(d_inode(dentry), uid); + /* we'll recheck under lock if there's anything to look in */ - if (dentry->d_fsdata) { + if (!ret && dentry->d_fsdata) { struct hlist_head *h = (struct hlist_head *)&dentry->d_fsdata; spin_lock(&dentry->d_lock); hlist_for_each_entry(fid, h, dlist) { @@ -106,9 +110,6 @@ static struct p9_fid *v9fs_fid_find(struct dentry *dentry, kuid_t uid, int any) } } spin_unlock(&dentry->d_lock); - } else { - if (dentry->d_inode) - ret = v9fs_fid_find_inode(dentry->d_inode, uid); } return ret; -- 2.17.1