[apparmor] How I found several bugs in less than an hour - without even searching for them

[Christian Boltz]

Hello,

Am Donnerstag, 13. August 2015 schrieb Steve Beattie:
> I'm currently in a situation where I don't have easy accesss to my
> regular environment, but I'm getting failures when running the tests
> with python2, like so:
> 
> ======================================================================
> ERROR: test_44306 (__main__.TestParseParserTests) test '{'exresult':
> u'PASS', 'tools_wrong': False, 'relfile': 'rlimits/ok_rlimit_01.sd',
> 'disabled': False, 'file':
> '/home/steve/bzr/apparmor/parser/tst/simple_tests/rlimits/ok_rlimit_0
> 1.sd', 'todo': False}'
...
>   File "/home/steve/bzr/apparmor/utils/apparmor/rule/rlimit.py", line
> 66, in __init__ raise AppArmorBug('Passed unknown object to
> RlimitRule: %s' % str(rlimit)) AppArmorBug: Passed unknown object to
> RlimitRule: cpu
> 
> ----------------------------------------------------------------------
> 
> I don't *think* it's due to a quirk in my setup. With python3, it
> passes all tests.

That looks like something Kshitij reported on IRC on June 18th, but we 
somehow failed to make a proper bugreport or patch out of it.

The problem is: You'll get a type() of "unicode" with py2, while it's 
"str" in py3. To make things even more interesting, py3 doesn't know 
anything about "unicode" and will throw a NameError if it hits that part 
of the condition. So basically you'll need to change all conditions like

    elif type(domain) == str:

to

    elif type(domain) == str or (py_2 and type(domain) == unicode):
    # py2 is pseudocode - in reality, you need to check sys.version

You'll find those checks in all rule classes, and usually more than one 
of them. 

Needless to say that the check looks a bit ugly and we need it in all 
rule classes - so if we want to fix it, we should wrap it as a 
is_string_in_this_py_version() function.

> (Granted, I would like to deprecate python2 in 2.11, making python3
> preferred, and then drop python2 support in 2.11+1.)

With the issue described above, 2.10 accidently is py3 only. So I tend 
to wait for bugreports [1] - and if we don't receive any, just silently 
require py3 instead of making the code a bit more ugly ;-)

BTW: are there any distributions that use the tools with py2? 
(openSUSE and Debian both use py3.)


Regards,

Christian Boltz

[1] starting aa-logprof with py2 should be enough to trigger the problem
-- 
I've chosen Suse for over 10 years, despite knowing that my computer
would be safest, enclosed in several feet of cement -- but it's really
hard to use that way... ;-)  [Linda Walsh in opensuse-factory]