Fwd: Bizzare bug in find, potential security implications

[Piotr Gackiewicz]

I think, PCRE does not have this problem.
What about implementing '-regextype pcre' ?
Dou You think it's a good idea?

Regards,

2017-12-19 23:01 GMT+01:00 Piotr Gackiewicz <address@hidden>:

> So, if it's by-design, users should be explicitly warned in man page:
>
> Do not rely on -regex, you could miss some badly encoded filenames.
>
> Or perhaps find could be enhanced with another regextype, non-posix and
> matching those ;-).
>
> Regards,
>
>
> 2017-12-19 22:48 GMT+01:00 Eric Blake <address@hidden>:
>
>> On 12/19/2017 03:31 PM, Bernhard Voelker wrote:
>>
>>
>>> The test case in your attachment is a bit different, but also shows
>>> the problem.  It seems that gnulib's regex does not find a match for
>>> the pattern '.*\.exe$' for the files in the following directory:
>>>
>>>    $ LC_ALL=C /usr/bin/ls -log htdocs
>>>    ...
>>>    drwxr-xr-x 2 4096 Dec 18 20:45 'Zielona G'$'\363''ra'
>>>    ...
>>>
>>> I'm not an expert on UTF and regex, but it seems that the $'\363'
>>> character is not matched by the dot '.' meta character in your
>>> locale.
>>>
>>
>> POSIX says that regex only has to match characters (in particular, the
>> glob '.' matches characters, not encoding errors).  If you pick a locale
>> with multibyte characters that are subject to encoding errors when
>> processing random bytes (as is the case when using a UTF-8 locale to
>> process single-byte ISO filenames), then POSIX says regex behavior is
>> undefined.  So while it is indeed annoying that find can't match files with
>> encoding errors, it is somewhat expected behavior, because there's no sane
>> way to make regex well-specified on encoding errors.
>>
>> --
>> Eric Blake, Principal Software Engineer
>> Red Hat, Inc.           +1-919-301-3266
>> Virtualization:  qemu.org | libvirt.org
>>
>
>
>
> --
> Piotr Gackiewicz
>

-- 
Piotr Gackiewicz