[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] file-posix: refuse to open directories
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] file-posix: refuse to open directories |
Date: |
Mon, 15 Jan 2018 14:23:07 +0100 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
Am 13.01.2018 um 00:30 hat John Snow geschrieben:
> On 12/22/2017 08:00 AM, Kevin Wolf wrote:
> > Am 21.12.2017 um 23:44 hat John Snow geschrieben:
> >> I don't think there's a legitimate reason to open directories as if
> >> they were files. This prevents QEMU from opening and attempting to probe
> >> a directory inode, which can break in exciting ways. One of those ways
> >> is lseek on ext4/xfs, which will return 0x7fffffffffffffff as the file
> >> size instead of EISDIR. This can coax QEMU into responding with a
> >> confusing "file too big" instead of "Hey, that's not a file".
> >>
> >> See: https://bugs.launchpad.net/qemu/+bug/1739304/
> >> Signed-off-by: John Snow <address@hidden>
> >> ---
> >> block/file-posix.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/block/file-posix.c b/block/file-posix.c
> >> index 36ee89e940..bd29bdada6 100644
> >> --- a/block/file-posix.c
> >> +++ b/block/file-posix.c
> >> @@ -589,6 +589,11 @@ static int raw_open_common(BlockDriverState *bs,
> >> QDict *options,
> >> s->needs_alignment = true;
> >> }
> >> #endif
> >> + if (S_ISDIR(st.st_mode)) {
> >> + ret = -EISDIR;
> >> + error_setg_errno(errp, errno, "Cannot open directory as file");
> >> + goto fail;
> >> + }
> >
> > I think instead of blacklisting directories, the callers should somehow
> > pass the file types they expect. Which would probably initially be
> > something like:
> >
> > file:
> > S_IFREG: expected
> > S_IFBLK or S_IFCHR: deprecation warning
> > else: error
> >
> > host_device / host_cdrom:
> > S_IFBLK or S_IFCHR: expected (which one depends on the OS)
> > else: error
> >
> > Kevin
> >
>
> "Hey, I'll just mask S_IFBLK and S_IFCHR into a field, and..."
>
> Oh, they're not mutually-bit-exclusive constants. That's... annoying.
The same thought process led to the "somehow" in my mail...
> Is there some un-annoying way to do this? I could create a new mask, and
> a new function to pick bits off the bitmask and check, and ...
>
> (it feels like a lot of spinning to accomplish not much.)
We have only two cases, so maybe just pass a bool device_node or
something? Or maybe we could check in the callers of raw_open_common()
afterwards instead of passing the information. But I think I like the
bool parameter better.
Kevin