From: Greg Kurz <groug@kaod.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Daniel Berrange <berrange@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
P J P <ppandit@redhat.com>, virtio-fs-list <virtio-fs@redhat.com>,
Alex Xu <alex@alxu.ca>, Laszlo Ersek <lersek@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v2] virtiofsd: prevent opening of special files (CVE-2020-35517)
Date: Wed, 27 Jan 2021 16:35:24 +0100 [thread overview]
Message-ID: <20210127163524.4e34596d@bahia.lan> (raw)
In-Reply-To: <CAOssrKc=kSQQLmrAR2VrKfDzkyNDEAAa5qusK1x6+-fCM4+yCA@mail.gmail.com>
On Wed, 27 Jan 2021 16:22:49 +0100
Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Wed, Jan 27, 2021 at 4:09 PM Greg Kurz <groug@kaod.org> wrote:
> >
> > On Wed, 27 Jan 2021 15:09:50 +0100
> > Miklos Szeredi <mszeredi@redhat.com> wrote:
> > > The semantics of O_CREATE are that it can fail neither because the
> > > file exists nor because it doesn't. This doesn't matter if the
> > > exported tree is not modified outside of a single guest, because of
> > > locking provided by the guest kernel.
> > >
> >
> > Wrong. O_CREAT can legitimately fail with ENOENT if one element
>
> Let me make my statement more precise:
>
> O_CREAT cannot fail with ENOENT if parent directory exists throughout
> the operation.
>
True, but I still don't see what guarantees guest userspace that the
parent directory doesn't go away... I must have missed something.
Please elaborate.
> I'm sure this property is used all over the place in userspace code,
> and hence should be supported in strict coherence (cache=none) mode.
>
> For relaxed coherence (cache=auto) I'm not quite sure. NFS is usually
> the reference, we'd need to look into what guarantees it provides wrt.
> O_CREAT and remote racing unlink.
>
> Thanks,
> Miklos
>
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kurz <groug@kaod.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Daniel Berrange <berrange@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
P J P <ppandit@redhat.com>, virtio-fs-list <virtio-fs@redhat.com>,
Alex Xu <alex@alxu.ca>, Stefan Hajnoczi <stefanha@redhat.com>,
Laszlo Ersek <lersek@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v2] virtiofsd: prevent opening of special files (CVE-2020-35517)
Date: Wed, 27 Jan 2021 16:35:24 +0100 [thread overview]
Message-ID: <20210127163524.4e34596d@bahia.lan> (raw)
In-Reply-To: <CAOssrKc=kSQQLmrAR2VrKfDzkyNDEAAa5qusK1x6+-fCM4+yCA@mail.gmail.com>
On Wed, 27 Jan 2021 16:22:49 +0100
Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Wed, Jan 27, 2021 at 4:09 PM Greg Kurz <groug@kaod.org> wrote:
> >
> > On Wed, 27 Jan 2021 15:09:50 +0100
> > Miklos Szeredi <mszeredi@redhat.com> wrote:
> > > The semantics of O_CREATE are that it can fail neither because the
> > > file exists nor because it doesn't. This doesn't matter if the
> > > exported tree is not modified outside of a single guest, because of
> > > locking provided by the guest kernel.
> > >
> >
> > Wrong. O_CREAT can legitimately fail with ENOENT if one element
>
> Let me make my statement more precise:
>
> O_CREAT cannot fail with ENOENT if parent directory exists throughout
> the operation.
>
True, but I still don't see what guarantees guest userspace that the
parent directory doesn't go away... I must have missed something.
Please elaborate.
> I'm sure this property is used all over the place in userspace code,
> and hence should be supported in strict coherence (cache=none) mode.
>
> For relaxed coherence (cache=auto) I'm not quite sure. NFS is usually
> the reference, we'd need to look into what guarantees it provides wrt.
> O_CREAT and remote racing unlink.
>
> Thanks,
> Miklos
>
next prev parent reply other threads:[~2021-01-27 15:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 10:35 [Virtio-fs] [PATCH v2] virtiofsd: prevent opening of special files (CVE-2020-35517) Stefan Hajnoczi
2021-01-26 10:35 ` Stefan Hajnoczi
2021-01-26 10:36 ` [Virtio-fs] " Daniel P. Berrangé
2021-01-26 10:36 ` Daniel P. Berrangé
2021-01-26 10:47 ` [Virtio-fs] " Liam Merwick
2021-01-26 17:16 ` Greg Kurz
2021-01-27 9:25 ` Miklos Szeredi
2021-01-27 9:25 ` Miklos Szeredi
2021-01-27 10:20 ` Greg Kurz
2021-01-27 10:20 ` Greg Kurz
2021-01-27 10:34 ` Miklos Szeredi
2021-01-27 10:34 ` Miklos Szeredi
2021-01-27 13:49 ` Greg Kurz
2021-01-27 13:49 ` Greg Kurz
2021-01-27 14:09 ` Miklos Szeredi
2021-01-27 14:09 ` Miklos Szeredi
2021-01-27 15:09 ` Greg Kurz
2021-01-27 15:09 ` Greg Kurz
2021-01-27 15:22 ` Miklos Szeredi
2021-01-27 15:22 ` Miklos Szeredi
2021-01-27 15:35 ` Greg Kurz [this message]
2021-01-27 15:35 ` Greg Kurz
2021-01-27 15:47 ` Miklos Szeredi
2021-01-27 15:47 ` Miklos Szeredi
2021-01-27 15:52 ` Miklos Szeredi
2021-01-27 15:52 ` Miklos Szeredi
2021-01-28 12:14 ` Greg Kurz
2021-01-28 12:14 ` Greg Kurz
2021-01-28 14:00 ` Miklos Szeredi
2021-01-28 14:00 ` Miklos Szeredi
2021-01-28 14:26 ` Greg Kurz
2021-01-28 14:26 ` Greg Kurz
2021-01-27 10:18 ` Stefan Hajnoczi
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=20210127163524.4e34596d@bahia.lan \
--to=groug@kaod.org \
--cc=alex@alxu.ca \
--cc=berrange@redhat.com \
--cc=lersek@redhat.com \
--cc=mszeredi@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--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: link
Be 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.