From: Miklos Szeredi <miklos@szeredi.hu> To: Greg Kurz <groug@kaod.org> Cc: virtio-fs-list <virtio-fs@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org, Vivek Goyal <vgoyal@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com> Subject: Re: [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN Date: Fri, 18 Jun 2021 10:58:33 +0200 [thread overview] Message-ID: <CAJfpegtpvU6Z6hQ-NKh-shN+Pux7+XzXwNK_Ro8YpfA-3tCOkg@mail.gmail.com> (raw) In-Reply-To: <20210617141518.304659-1-groug@kaod.org> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Miklos Szeredi <miklos@szeredi.hu> To: Greg Kurz <groug@kaod.org> Cc: virtio-fs-list <virtio-fs@redhat.com>, qemu-devel@nongnu.org, Vivek Goyal <vgoyal@redhat.com> Subject: Re: [Virtio-fs] [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN Date: Fri, 18 Jun 2021 10:58:33 +0200 [thread overview] Message-ID: <CAJfpegtpvU6Z6hQ-NKh-shN+Pux7+XzXwNK_Ro8YpfA-3tCOkg@mail.gmail.com> (raw) In-Reply-To: <20210617141518.304659-1-groug@kaod.org> 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 >
next prev parent reply other threads:[~2021-06-18 9:03 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-17 14:15 [PATCH] virtiofsd: Don't allow file creation with FUSE_OPEN Greg Kurz 2021-06-17 14:15 ` [Virtio-fs] " Greg Kurz 2021-06-17 14:29 ` Dr. David Alan Gilbert 2021-06-17 14:29 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-17 16:18 ` Greg Kurz 2021-06-17 16:18 ` [Virtio-fs] " Greg Kurz 2021-06-18 1:40 ` Vivek Goyal 2021-06-18 1:40 ` [Virtio-fs] " Vivek Goyal 2021-06-18 8:20 ` Greg Kurz 2021-06-18 8:20 ` [Virtio-fs] " Greg Kurz 2021-06-18 8:58 ` Miklos Szeredi [this message] 2021-06-18 8:58 ` Miklos Szeredi 2021-06-18 9:21 ` Greg Kurz 2021-06-18 9:21 ` [Virtio-fs] " Greg Kurz 2021-06-18 9:34 ` Miklos Szeredi 2021-06-18 9:34 ` [Virtio-fs] " Miklos Szeredi 2021-06-21 13:36 ` Stefan Hajnoczi 2021-06-21 13:36 ` [Virtio-fs] " Stefan Hajnoczi 2021-06-22 16:01 ` Greg Kurz 2021-06-22 16:01 ` [Virtio-fs] " Greg Kurz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJfpegtpvU6Z6hQ-NKh-shN+Pux7+XzXwNK_Ro8YpfA-3tCOkg@mail.gmail.com \ --to=miklos@szeredi.hu \ --cc=dgilbert@redhat.com \ --cc=groug@kaod.org \ --cc=qemu-devel@nongnu.org \ --cc=stefanha@redhat.com \ --cc=vgoyal@redhat.com \ --cc=virtio-fs@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.