From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea8mo-0006Ka-7A for qemu-devel@nongnu.org; Fri, 12 Jan 2018 18:30:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ea8mn-0000I9-2H for qemu-devel@nongnu.org; Fri, 12 Jan 2018 18:30:58 -0500 References: <20171221224411.8901-1-jsnow@redhat.com> <20171222130018.GE3763@localhost.localdomain> From: John Snow Message-ID: <00bb48ca-52e9-e6d1-9a84-d78144464ab3@redhat.com> Date: Fri, 12 Jan 2018 18:30:47 -0500 MIME-Version: 1.0 In-Reply-To: <20171222130018.GE3763@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] file-posix: refuse to open directories List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: mreitz@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org, dgilbert@redhat.com 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 >> --- >> 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. 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.) --js