[apparmor] GSoC r13, r14, r15 review

[Kshitij Gupta]

>> Traceback (most recent call last):
>>   File "../apparmor/severity.py", line 76, in __init__
>>     resource, severity = line.split()
>> ValueError: need more than 1 value to unpack
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "severity_test.py", line 20, in testInvalid
>>     broken = severity.Severity('severity_broken.db')
>>   File "../apparmor/severity.py", line 79, in __init__
>>     raise AppArmorException("No severity value present in file:
>> %s\n\t[Line %s]: %s" % (dbname, lineno, line))
>> apparmor.common.AppArmorException: 'No severity value present in file:
>> severity_broken.db\n\t[Line 14]: CAP_SYS_MODULE'
>>
>> ----------------------------------------------------------------------
>> Ran 2 tests in 0.541s
>>
>> FAILED (errors=1)
>>
>> I somehow doubt this is intentional - the test should catch this
>> exception ;-)
>>
As it turns this issue has got something to do with the Python3's new
feature called Exception Chaining.
Its another of those Python2-3 problem.
An additional line needs to be incorporated to check if Python2 or 3
and raise accordingly. :/

> It was inside the try except block of test, I got it out to try how
> exception looked.
> Turns out \n\t aren't working yet. :-\
>> Also note that the last line contains \n\t - this should become a real
>> line break and tab in the output...
>>
>
I did not notice until later, but the AppArmorException uses repr() to
print the description and hence its not possible to print the nicely
formatted exception with the line number in new line.
I feel I should use the error(), it will print something like this and
terminate program:

ERROR: No severity value present in file: severity_broken.db
    [Line 14]: CAP_SYS_MODULE
What would you say? move to error() instead of raising AppArmorException?

Regards,

Kshitij Gupta