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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B83D7C2B9F4 for ; Fri, 18 Jun 2021 01:41:34 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1E15B61001 for ; Fri, 18 Jun 2021 01:41:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E15B61001 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lu3Vl-0003YK-4C for qemu-devel@archiver.kernel.org; Thu, 17 Jun 2021 21:41:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lu3Uh-0002nH-9n for qemu-devel@nongnu.org; Thu, 17 Jun 2021 21:40:27 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:37938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lu3Ud-0000D9-2R for qemu-devel@nongnu.org; Thu, 17 Jun 2021 21:40:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623980421; 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: in-reply-to:in-reply-to:references:references; bh=iDugXN3b3s4sc5QxCRs0sbFZFIYzheDaodxuufrf52w=; b=Zmv/rkOfskpgkcUVQavDSnKozFGdr55dBHT3XczshhPR8drb6e5W9PcK3+3jNavTYuhHQP teWCoPW85xL7Ds6ljzfbfJAmEhGm47zEpqICiOt4eKy/ZDD07muLszfmsqGls6liALr09a p7E7Q0mCfdDTS5EACPbfvNUZ/2ILyy0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-9-NSRdSLvOMsCOCFaZveQ-Mw-1; Thu, 17 Jun 2021 21:40:20 -0400 X-MC-Unique: NSRdSLvOMsCOCFaZveQ-Mw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1E740100B381; Fri, 18 Jun 2021 01:40:18 +0000 (UTC) Received: from horse.redhat.com (ovpn-116-162.rdu2.redhat.com [10.10.116.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id B793910016F4; Fri, 18 Jun 2021 01:40:07 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 4BB98220BCF; Thu, 17 Jun 2021 21:40:07 -0400 (EDT) Date: Thu, 17 Jun 2021 21:40:07 -0400 From: Vivek Goyal To: Greg Kurz Subject: Re: [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN Message-ID: <20210618014007.GA1219970@redhat.com> References: <20210617141518.304659-1-groug@kaod.org> MIME-Version: 1.0 In-Reply-To: <20210617141518.304659-1-groug@kaod.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vgoyal@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=vgoyal@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.197, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: virtio-fs@redhat.com, Miklos Szeredi , qemu-devel@nongnu.org, Stefan Hajnoczi , "Dr. David Alan Gilbert" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Jun 17, 2021 at 04:15:18PM +0200, Greg Kurz wrote: > A well behaved FUSE client uses FUSE_CREATE to create files. It isn't > supposed to pass O_CREAT along a FUSE_OPEN request, as documented in > the "fuse_lowlevel.h" header : > > /** > * Open a file > * > * Open flags are available in fi->flags. The following rules > * apply. > * > * - Creation (O_CREAT, O_EXCL, O_NOCTTY) flags will be > * filtered out / handled by the kernel. > > But if it does anyway, virtiofsd crashes with: > > *** invalid openat64 call: O_CREAT or O_TMPFILE without mode ***: terminated So did you hit this error with current fuse client. If yes, that means client needs fixing as well? Or you are doing this fix based on comment in fuse_lowlevel.h. I am wondering why this protocl restriction is there that open() path should not be able to honor O_CREAT. Vivek > > This is because virtiofsd ends up passing this flag to openat() without > passing a mode_t 4th argument which is mandatory with O_CREAT, and glibc > aborts. > > The offending path is: > > lo_open() > lo_do_open() > lo_inode_open() > > Other callers of lo_inode_open() only pass O_RDWR and lo_create() > passes a valid fd to lo_do_open() which thus doesn't even call > lo_inode_open() in this case. > > Specifying O_CREAT with FUSE_OPEN is a protocol violation. Check this > in lo_open() and return an error to the client : EINVAL since this is > already what glibc returns with other illegal flag combinations. > > The FUSE filesystem doesn't currently support O_TMPFILE, but the very > same would happen if O_TMPFILE was passed in a FUSE_OPEN request. Check > that as well. > > Signed-off-by: Greg Kurz > --- > tools/virtiofsd/passthrough_ll.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c > index 49c21fd85570..14f62133131c 100644 > --- a/tools/virtiofsd/passthrough_ll.c > +++ b/tools/virtiofsd/passthrough_ll.c > @@ -2145,6 +2145,12 @@ static void lo_open(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi) > return; > } > > + /* File creation is handled by lo_create() */ > + if (fi->flags & (O_CREAT | O_TMPFILE)) { > + fuse_reply_err(req, EINVAL); > + return; > + } > + > err = lo_do_open(lo, inode, -1, fi); > lo_inode_put(lo, &inode); > if (err) { > -- > 2.31.1 >