Re: [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN

[Greg Kurz]

On Mon, 21 Jun 2021 14:36:12 +0100
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> 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
> > 
> > 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 <groug@kaod.org>
> > ---
> >  tools/virtiofsd/passthrough_ll.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> 
> Thank you!
> 
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Upstream libfuse folks suggested to do the change in fuse_lowlevel.c so
that it fixes all filesystems, not only those based on passthrough_ll.c.

I'll thus post a new version.

They also seemed to be a little concerned by open() returning EINVAL
to the end user who did nothing wrong (kernel did). They suggested
that the server should rather print out an error and exit... which
isn't really an option for us. And anyway, we already return EINVAL
when we can't extract the arguments of the request. So I won't
address this concern, but I still wanted to share it here.

pgpXE3rWR35Q6.pgp
Description: OpenPGP digital signature