Re: [Qemu-block] [Qemu-devel] [PATCH v4] file-posix: specify expected filetypes

2018-03-19 Thread John Snow


On 03/19/2018 11:29 AM, Kevin Wolf wrote:
> Am 13.03.2018 um 18:20 hat John Snow geschrieben:
>>
>>
>> On 01/19/2018 06:03 PM, Eric Blake wrote:
>>> On 01/19/2018 04:47 PM, John Snow wrote:
 Adjust each caller of raw_open_common to specify if they are expecting
 host and character devices or not. Tighten expectations of file types upon
 open in the common code and refuse types that are not expected.

 This has two effects:

 (1) Character and block devices are now considered deprecated for the
 'file' driver, which expects only S_IFREG, and
 (2) no file-posix driver (file, host_cdrom, or host_device) can open
 directories now.

 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 0x7fff 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 
 ---
>>>
>>> Reviewed-by: Eric Blake 
>>
>> Whoops, I let this one rot. It could still be considered a bugfix for
>> next week.
> 
> Yes, we should take this as a bugfix. Needs a rebase, though.
> 
> Kevin
> 

You got it.

--js



Re: [Qemu-block] [Qemu-devel] [PATCH v4] file-posix: specify expected filetypes

2018-03-19 Thread Kevin Wolf
Am 13.03.2018 um 18:20 hat John Snow geschrieben:
> 
> 
> On 01/19/2018 06:03 PM, Eric Blake wrote:
> > On 01/19/2018 04:47 PM, John Snow wrote:
> >> Adjust each caller of raw_open_common to specify if they are expecting
> >> host and character devices or not. Tighten expectations of file types upon
> >> open in the common code and refuse types that are not expected.
> >>
> >> This has two effects:
> >>
> >> (1) Character and block devices are now considered deprecated for the
> >> 'file' driver, which expects only S_IFREG, and
> >> (2) no file-posix driver (file, host_cdrom, or host_device) can open
> >> directories now.
> >>
> >> 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 0x7fff 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 
> >> ---
> > 
> > Reviewed-by: Eric Blake 
> 
> Whoops, I let this one rot. It could still be considered a bugfix for
> next week.

Yes, we should take this as a bugfix. Needs a rebase, though.

Kevin



Re: [Qemu-block] [Qemu-devel] [PATCH v4] file-posix: specify expected filetypes

2018-01-19 Thread Eric Blake
On 01/19/2018 04:47 PM, John Snow wrote:
> Adjust each caller of raw_open_common to specify if they are expecting
> host and character devices or not. Tighten expectations of file types upon
> open in the common code and refuse types that are not expected.
> 
> This has two effects:
> 
> (1) Character and block devices are now considered deprecated for the
> 'file' driver, which expects only S_IFREG, and
> (2) no file-posix driver (file, host_cdrom, or host_device) can open
> directories now.
> 
> 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 0x7fff 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 
> ---

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature