Re: [Qemu-devel] [PATCH] file-posix: refuse to open directories

[John Snow <jsnow@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 <jsnow@redhat.com>
>> ---
>>  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