From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B929C433EF for ; Wed, 8 Sep 2021 10:34:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 76D7B61163 for ; Wed, 8 Sep 2021 10:34:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348892AbhIHKgG (ORCPT ); Wed, 8 Sep 2021 06:36:06 -0400 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]:37248 "EHLO out30-57.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234958AbhIHKgD (ORCPT ); Wed, 8 Sep 2021 06:36:03 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0UngnJV5_1631097293; Received: from admindeMacBook-Pro-2.local(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UngnJV5_1631097293) by smtp.aliyun-inc.com(127.0.0.1); Wed, 08 Sep 2021 18:34:53 +0800 Subject: Re: [Virtio-fs] [virtiofsd PATCH v4 4/4] virtiofsd: support per-file DAX in FUSE_LOOKUP To: Greg Kurz Cc: "Dr. David Alan Gilbert" , miklos@szeredi.hu, virtualization@lists.linux-foundation.org, virtio-fs@redhat.com, joseph.qi@linux.alibaba.com, stefanha@redhat.com, linux-fsdevel@vger.kernel.org, vgoyal@redhat.com References: <20210817022220.17574-1-jefflexu@linux.alibaba.com> <20210817022347.18098-1-jefflexu@linux.alibaba.com> <20210817022347.18098-5-jefflexu@linux.alibaba.com> <29627110-e4bf-836f-2343-1faeb36ad4d3@linux.alibaba.com> <4494052b-aff1-e2e3-e704-c8743168f62e@linux.alibaba.com> <20210824121515.5419d6a7@bahia.lan> From: JeffleXu Message-ID: <88041d90-d170-3ae1-903e-2fa32e51027f@linux.alibaba.com> Date: Wed, 8 Sep 2021 18:34:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210824121515.5419d6a7@bahia.lan> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 8/24/21 6:15 PM, Greg Kurz wrote: > On Fri, 20 Aug 2021 13:03:23 +0800 > JeffleXu wrote: >> >> Fine. Got it. However the returned fd (opened without O_PATH) is only >> used for FS_IOC_GETFLAGS/FS_IOC_FSGETXATTR ioctl, while in most cases >> for special device files, these two ioctls should return -ENOTTY. >> > > The actual problem is that a FIFO will cause openat() to block until > the other end of the FIFO is open for writing... Got it. > >> If it's really a security issue, then lo_inode_open() could be used to > > ... and cause a DoS on virtiofsd. So yes, this is a security issue and > lo_inode_open() was introduced specifically to handle this. > >> get a temporary fd, i.e., check if it's a special file before opening. >> After all, FUSE_OPEN also handles in this way. Besides, I can't >> understand what "race-free way" means. >> > > "race-free way" means a way that guarantees that file type > cannot change between the time you check it and the time > you open it (TOCTOU error). For example, doing a plain stat(), > checking st_mode and proceeding to open() is wrong : nothing > prevents the file to be unlinked and replaced by something > else between stat() and open(). > > We avoid that by keeping O_PATH fds around and using > lo_inode_open() instead of openat(). Thanks for the detailed explanation. Got it. > > In your case, it seems that you should do the checking after > you have an actual lo_inode for the target file, and pass > that to lo_should_enable_dax() instead of the parent lo_inode > and target name. > Yes, that will be more reasonable. Thanks. -- Thanks, Jeffle