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

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

[Greg Kurz]

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(+)

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

[Virtio-fs] [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN

[Greg Kurz]

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(+)

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

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

[Dr. David Alan Gilbert]

* Greg Kurz (groug@kaod.org) 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>

That seems reasonable, so

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

should you also send a corresponding patch for libfuse's example code
we're based on?

Dave

> ---
>  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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Dr. David Alan Gilbert]

* Greg Kurz (groug@kaod.org) 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>

That seems reasonable, so

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

should you also send a corresponding patch for libfuse's example code
we're based on?

Dave

> ---
>  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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Greg Kurz]

On Thu, 17 Jun 2021 15:29:12 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * Greg Kurz (groug@kaod.org) 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>
> 
> That seems reasonable, so
> 
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> 
> should you also send a corresponding patch for libfuse's example code
> we're based on?
> 

Good idea. I've just done that.

Cheers,

--
Greg

> Dave
> 
> > ---
> >  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
> > 

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

[Greg Kurz]

On Thu, 17 Jun 2021 15:29:12 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * Greg Kurz (groug@kaod.org) 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>
> 
> That seems reasonable, so
> 
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> 
> should you also send a corresponding patch for libfuse's example code
> we're based on?
> 

Good idea. I've just done that.

Cheers,

--
Greg

> Dave
> 
> > ---
> >  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
> > 

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

[Vivek Goyal]

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 <groug@kaod.org>
> ---
>  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
> 

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

[Vivek Goyal]

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 <groug@kaod.org>
> ---
>  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
> 

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

[Greg Kurz]

On Thu, 17 Jun 2021 21:40:07 -0400
Vivek Goyal <vgoyal@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 also the consequence of virtiofsd being compiled with
-D_FORTIFY_SOURCE=2. Without that, no abort but arbitrary data
is passed as mode_t argument to the openat() syscall instead.

> So did you hit this error with current fuse client. If yes, that means
> client needs fixing as well?
> 

I've patched the client to cause this:

--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -28,6 +28,7 @@ static int fuse_send_open(struct fuse_mount *fm, u64 nodeid,
 
        memset(&inarg, 0, sizeof(inarg));
        inarg.flags = open_flags & ~(O_CREAT | O_EXCL | O_NOCTTY);
+       if (opcode == FUSE_OPEN) inarg.flags |= O_TMPFILE;
        if (!fm->fc->atomic_o_trunc)
                inarg.flags &= ~O_TRUNC;


> 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.
> 

It isn't a protocol restriction IMHO. The distinction between file
creation and file opening has always been there since the start.
Older versions of the protocol would send FUSE_MKNOD to create a
file and then send FUSE_OPEN to open it. Because this was racy,
FUSE_CREATE was introduced at some point to do both operations
atomically.

Question is : what would be the semantics of O_CREAT in FUSE_OPEN ?

> 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 <groug@kaod.org>
> > ---
> >  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
> > 
> 

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

[Greg Kurz]

On Thu, 17 Jun 2021 21:40:07 -0400
Vivek Goyal <vgoyal@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 also the consequence of virtiofsd being compiled with
-D_FORTIFY_SOURCE=2. Without that, no abort but arbitrary data
is passed as mode_t argument to the openat() syscall instead.

> So did you hit this error with current fuse client. If yes, that means
> client needs fixing as well?
> 

I've patched the client to cause this:

--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -28,6 +28,7 @@ static int fuse_send_open(struct fuse_mount *fm, u64 nodeid,
 
        memset(&inarg, 0, sizeof(inarg));
        inarg.flags = open_flags & ~(O_CREAT | O_EXCL | O_NOCTTY);
+       if (opcode == FUSE_OPEN) inarg.flags |= O_TMPFILE;
        if (!fm->fc->atomic_o_trunc)
                inarg.flags &= ~O_TRUNC;


> 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.
> 

It isn't a protocol restriction IMHO. The distinction between file
creation and file opening has always been there since the start.
Older versions of the protocol would send FUSE_MKNOD to create a
file and then send FUSE_OPEN to open it. Because this was racy,
FUSE_CREATE was introduced at some point to do both operations
atomically.

Question is : what would be the semantics of O_CREAT in FUSE_OPEN ?

> 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 <groug@kaod.org>
> > ---
> >  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
> > 
> 

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

[Miklos Szeredi]

On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
>
> 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;
> +    }
> +

Okay.  Question comes to mind whether the check should be even more
strict, possibly allowing just a specific set of flags, and erroring
out on everything else?

AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:

O_RDONLY
O_WRONLY
O_RDWR
O_APPEND
O_NDELAY
O_NONBLOCK
__O_SYNC
O_DSYNC
FASYNC
O_DIRECT
O_LARGEFILE
O_NOFOLLOW
O_NOATIME

A separate question is whether virtiofsd should also be silently
ignoring some of the above flags.

Thanks,
Miklos



>      err = lo_do_open(lo, inode, -1, fi);
>      lo_inode_put(lo, &inode);
>      if (err) {
> --
> 2.31.1
>

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

[Miklos Szeredi]

On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
>
> 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;
> +    }
> +

Okay.  Question comes to mind whether the check should be even more
strict, possibly allowing just a specific set of flags, and erroring
out on everything else?

AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:

O_RDONLY
O_WRONLY
O_RDWR
O_APPEND
O_NDELAY
O_NONBLOCK
__O_SYNC
O_DSYNC
FASYNC
O_DIRECT
O_LARGEFILE
O_NOFOLLOW
O_NOATIME

A separate question is whether virtiofsd should also be silently
ignoring some of the above flags.

Thanks,
Miklos



>      err = lo_do_open(lo, inode, -1, fi);
>      lo_inode_put(lo, &inode);
>      if (err) {
> --
> 2.31.1
>

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

[Greg Kurz]

On Fri, 18 Jun 2021 10:58:33 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:

> On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
> >
> > 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;
> > +    }
> > +
> 
> Okay.  Question comes to mind whether the check should be even more
> strict, possibly allowing just a specific set of flags, and erroring
> out on everything else?
> 

I've focused on O_CREAT and O_TMPFILE because they cause an explicit abort()
in glibc when the code is compiled with -D_FORTIFY_SOURCE=2, but yes,
maybe it could make sense to check more of them.

> AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:
> 
> O_RDONLY
> O_WRONLY
> O_RDWR
> O_APPEND
> O_NDELAY
> O_NONBLOCK
> __O_SYNC
> O_DSYNC
> FASYNC
> O_DIRECT
> O_LARGEFILE
> O_NOFOLLOW
> O_NOATIME
> 
> A separate question is whether virtiofsd should also be silently
> ignoring some of the above flags.
> 

Dunno on the top of my head...

BTW, as suggested by Dave, I've submitted a similar patch to upstream
libfuse:

https://github.com/libfuse/libfuse/pull/615

And I got interesting suggestions:
1) do it in core FUSE, i.e. fuse_lowlevel.c, since this isn't specific to
   passthrough_ll AFAICT
2) print out an error
3) exit

1 makes a lot of sense. I guess 2 is fine this cannot be used by a
buggy guest to flood some log file on the host. 3 doesn't seems
to be an acceptable solution, and it wouldn't change much the
outcome compared to what we have now.

So I will go for 1 and 2.

Cheers,

--
Greg

> Thanks,
> Miklos
> 
> 
> 
> >      err = lo_do_open(lo, inode, -1, fi);
> >      lo_inode_put(lo, &inode);
> >      if (err) {
> > --
> > 2.31.1
> >

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

[Greg Kurz]

On Fri, 18 Jun 2021 10:58:33 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:

> On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
> >
> > 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;
> > +    }
> > +
> 
> Okay.  Question comes to mind whether the check should be even more
> strict, possibly allowing just a specific set of flags, and erroring
> out on everything else?
> 

I've focused on O_CREAT and O_TMPFILE because they cause an explicit abort()
in glibc when the code is compiled with -D_FORTIFY_SOURCE=2, but yes,
maybe it could make sense to check more of them.

> AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:
> 
> O_RDONLY
> O_WRONLY
> O_RDWR
> O_APPEND
> O_NDELAY
> O_NONBLOCK
> __O_SYNC
> O_DSYNC
> FASYNC
> O_DIRECT
> O_LARGEFILE
> O_NOFOLLOW
> O_NOATIME
> 
> A separate question is whether virtiofsd should also be silently
> ignoring some of the above flags.
> 

Dunno on the top of my head...

BTW, as suggested by Dave, I've submitted a similar patch to upstream
libfuse:

https://github.com/libfuse/libfuse/pull/615

And I got interesting suggestions:
1) do it in core FUSE, i.e. fuse_lowlevel.c, since this isn't specific to
   passthrough_ll AFAICT
2) print out an error
3) exit

1 makes a lot of sense. I guess 2 is fine this cannot be used by a
buggy guest to flood some log file on the host. 3 doesn't seems
to be an acceptable solution, and it wouldn't change much the
outcome compared to what we have now.

So I will go for 1 and 2.

Cheers,

--
Greg

> Thanks,
> Miklos
> 
> 
> 
> >      err = lo_do_open(lo, inode, -1, fi);
> >      lo_inode_put(lo, &inode);
> >      if (err) {
> > --
> > 2.31.1
> >

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

[Miklos Szeredi]

On Fri, 18 Jun 2021 at 11:21, Greg Kurz <groug@kaod.org> wrote:
>
> On Fri, 18 Jun 2021 10:58:33 +0200
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
> > >
> > > 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;
> > > +    }
> > > +
> >
> > Okay.  Question comes to mind whether the check should be even more
> > strict, possibly allowing just a specific set of flags, and erroring
> > out on everything else?
> >
>
> I've focused on O_CREAT and O_TMPFILE because they cause an explicit abort()
> in glibc when the code is compiled with -D_FORTIFY_SOURCE=2, but yes,
> maybe it could make sense to check more of them.
>
> > AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:
> >
> > O_RDONLY
> > O_WRONLY
> > O_RDWR
> > O_APPEND
> > O_NDELAY
> > O_NONBLOCK
> > __O_SYNC
> > O_DSYNC
> > FASYNC
> > O_DIRECT
> > O_LARGEFILE
> > O_NOFOLLOW
> > O_NOATIME
> >
> > A separate question is whether virtiofsd should also be silently
> > ignoring some of the above flags.
> >
>
> Dunno on the top of my head...

Let's discuss this separately as this is mostly unrelated.  Added an
item to the virtiofs-todo etherpad.

>
> BTW, as suggested by Dave, I've submitted a similar patch to upstream
> libfuse:
>
> https://github.com/libfuse/libfuse/pull/615
>
> And I got interesting suggestions:
> 1) do it in core FUSE, i.e. fuse_lowlevel.c, since this isn't specific to
>    passthrough_ll AFAICT
> 2) print out an error
> 3) exit
>
> 1 makes a lot of sense. I guess 2 is fine this cannot be used by a
> buggy guest to flood some log file on the host. 3 doesn't seems
> to be an acceptable solution, and it wouldn't change much the
> outcome compared to what we have now.
>
> So I will go for 1 and 2.

Okay, good.

Thanks,
Miklos

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

[Miklos Szeredi]

On Fri, 18 Jun 2021 at 11:21, Greg Kurz <groug@kaod.org> wrote:
>
> On Fri, 18 Jun 2021 10:58:33 +0200
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > On Thu, 17 Jun 2021 at 16:15, Greg Kurz <groug@kaod.org> 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(+)
> > >
> > > 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;
> > > +    }
> > > +
> >
> > Okay.  Question comes to mind whether the check should be even more
> > strict, possibly allowing just a specific set of flags, and erroring
> > out on everything else?
> >
>
> I've focused on O_CREAT and O_TMPFILE because they cause an explicit abort()
> in glibc when the code is compiled with -D_FORTIFY_SOURCE=2, but yes,
> maybe it could make sense to check more of them.
>
> > AFAICS linux kernel should never pass anything to FUSE_OPEN outside of this set:
> >
> > O_RDONLY
> > O_WRONLY
> > O_RDWR
> > O_APPEND
> > O_NDELAY
> > O_NONBLOCK
> > __O_SYNC
> > O_DSYNC
> > FASYNC
> > O_DIRECT
> > O_LARGEFILE
> > O_NOFOLLOW
> > O_NOATIME
> >
> > A separate question is whether virtiofsd should also be silently
> > ignoring some of the above flags.
> >
>
> Dunno on the top of my head...

Let's discuss this separately as this is mostly unrelated.  Added an
item to the virtiofs-todo etherpad.

>
> BTW, as suggested by Dave, I've submitted a similar patch to upstream
> libfuse:
>
> https://github.com/libfuse/libfuse/pull/615
>
> And I got interesting suggestions:
> 1) do it in core FUSE, i.e. fuse_lowlevel.c, since this isn't specific to
>    passthrough_ll AFAICT
> 2) print out an error
> 3) exit
>
> 1 makes a lot of sense. I guess 2 is fine this cannot be used by a
> buggy guest to flood some log file on the host. 3 doesn't seems
> to be an acceptable solution, and it wouldn't change much the
> outcome compared to what we have now.
>
> So I will go for 1 and 2.

Okay, good.

Thanks,
Miklos

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]