Date: Thu, 7 Mar 2019 10:36:39 -0800 From: Conrad Meyer <cem@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r344857 - head/sys/fs/fuse Message-ID: <CAG6CVpUi4Of24OH5MHcd-vj1%2B5GkiE-WZeMbj2__KQbiCOouMQ@mail.gmail.com> In-Reply-To: <20190307105959.GJ2492@kib.kiev.ua> References: <201903062256.x26Munf3054948@repo.freebsd.org> <20190307105959.GJ2492@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Konstantin, On Thu, Mar 7, 2019 at 3:00 AM Konstantin Belousov <kostikbel@gmail.com> wrote: > > On Wed, Mar 06, 2019 at 10:56:49PM +0000, Conrad Meyer wrote: > > FUSE: Prevent trivial panic > > > > When open(2) was invoked against a FUSE filesystem with an unexpected flags > > value (no O_RDONLY / O_RDWR / O_WRONLY), an assertion fired, causing panic. > > Did you miss O_EXEC ? Nope. > O_RDONLY is defined as zero, and we interpret the > flags as having O_RDONLY if no other flags were passed. The commit message probably could have been more clear. The check that we actually perform (and guard against with this change) is ((flags & (FREAD | FWRITE)) == 0). FREAD is non-zero. Alan has empirically demonstrated that O_EXEC at the open(2) layer does not translate into a FREAD flag at the VOP_OPEN() layer. > VFS guarantees that one of the O_EXEC/FREAD/FWRITE flag is always > there. If it does not, it is bug. See the code at the start of > kern_openat(). Sure. FUSE is not prepared to handle (flags & (O_EXEC|FREAD|FWRITE)) == O_EXEC at this time. This revision just changes that (user-inducible) scenario into an error, instead of a panic. Like the commit message says, it is not intended to be the correct long-term solution. Best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpUi4Of24OH5MHcd-vj1%2B5GkiE-WZeMbj2__KQbiCOouMQ>