[apparmor] [Patch][parser]

[John Johansen]

On 09/24/2014 01:31 PM, Tyler Hicks wrote:
> On 2014-09-24 15:00:27, Tyler Hicks wrote:
>> On 2014-09-24 11:32:33, John Johansen wrote:
>>> Fix: Parser error when using regex profile names in IPC rules
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/1373085
>>>
>>> The parser fails to accept certain characters, even when escaped or quoted
>>> as part of the profile or label name in ipc rules. This is due to the
>>> lexer not accepting those characters as part of the input pattern.
>>>
>>> Signed-off-by: John Johansen <john.johansen at canonical.com>
>>
>> Bug fixes like this should include tests.
> 
> This patch causes make check in the parser/ dir to fail:
> 
>   not ok 91 - ./simple_tests//dbus/bad_regex_03.sd: dbus rule with a bad peer regex expansion
> 
> The test is intended to make sure that this rule fails to compile:
> 
>   dbus send bus=session peer=(label=splat\ ),
> 
> However, it passes with the patch applied.
> 
> Here's the dfa-states dump:
> 
> $ echo "/t { dbus send bus=session peer=(label=splat\ ), }" |
> ./parser/apparmor_parser -qQD dfa-states
> {1} <== (allow/deny/audit/quiet)
> {2} (0x 4/0/0/0)
> {3} (0x 4/0/0/0)
> {23} (0x 2/0/0/0)
> 
> {1} -> {2}: 0x2
> {1} -> {2}: 0x4
> {1} -> {2}: 0x7
> {1} -> {2}: 0x9
> {1} -> {2}: 0xa
> {1} -> {3}: 0x20 \ 
> {1} -> {4}: 0x34 4
> {3}  (0x 4/0/0/0) -> {5}: 0x73 s
> {4} -> {6}: 0x0
> {5} -> {7}: 0x65 e
> {6} -> {2}: 0x31 1
> {7} -> {8}: 0x73 s
> {8} -> {9}: 0x73 s
> {9} -> {10}: 0x69 i
> {10} -> {11}: 0x6f o
> {11} -> {12}: 0x6e n
> {12} -> {13}: 0x0
> {13} -> {14}: 0x0
> {13} -> {13}: []
> {14} -> {15}: 0x73 s
> {15} -> {16}: 0x70 p
> {16} -> {17}: 0x6c l
> {17} -> {18}: 0x61 a
> {18} -> {19}: 0x74 t
> {19} -> {20}: 0x20 \ 
> {20} -> {21}: 0x0
> {21} -> {22}: 0x0
> {21} -> {21}: []
> {22} -> {23}: 0x0
> {22} -> {22}: []
> {23}  (0x 2/0/0/0) -> {23}: [^\0x0]
> 
> It seems to be doing the right thing by discarding the backslash and
> including the space (0x20) as part of the match string.
> 
> I think this fix makes the test bad since we can now handle such a
> sequence in the peer conditional, right?
> 
yep, this fixes it so we can handle escaped spaces correctly, so we can
modify the test to be a case of passing