Re: Why is /usr/include matched with /usr/inclu.e?

On 8/21/19 4:29 PM, Nicolas Iooss wrote:
> On Wed, Aug 21, 2019 at 10:02 PM Dominick Grift <[email protected]> wrote:
>>
>> On Wed, Aug 21, 2019 at 09:57:14PM +0200, Nicolas Iooss wrote:
>>> Hi all,
>>>
>>> While checking the patterns in refpolicy, I stumbled upon the
>>> following line in
>>> https://github.com/SELinuxProject/refpolicy/blob/RELEASE_2_20190609/policy/modules/kernel/files.fc#L200
>>>
>>> /usr/inclu.e(/.*)? gen_context(system_u:object_r:usr_t,s0)
>>
>> Probably to work around an m4-ism. There seems to be an m4 "include" built-in.
> 
> This seems to be a good explanation. The policy also uses workarounds
> for "index" built-in, with:
> 
> /etc/amanda/.*/index`'(/.*)?
> /var/lib/apt-xapian-inde(x)(/.*)?
> 
> In order not to introduce parentheses (which might change some
> ordering in the way the paths are matched with the patterns), I am
> thinking of replacing the pattern of /usr/include with:
> 
> /usr/includ[e](/.*)? gen_context(system_u:object_r:usr_t,s0)
> 
> ... with a comment about working around a m4 issue.

My preference would be an empty m4 string (`') over some regex trick, if 
possible, so the sorting isn't upset.

-- 
Chris PeBenito