[python2] aa-logprof: AppArmorBug: Passed unknown object to NetworkRule: inet

[Hans Kristian Rosbach]

This is on Scientific Linux 7.1 (RHEL clone).
Compiled from Apparmor 2.10.0 release.

It seems to me that logprof cannot handle the "inet" keyword
used in several of the (abstraction) profiles.

aa-logprof consistently crashes with this message.

# aa-logprof
Traceback (most recent call last):
  File "/usr/sbin/aa-logprof", line 48, in <module>
    apparmor.loadincludes()
  File "/usr/lib/python2.7/site-packages/apparmor/aa.py", line 4269, in loadincludes
    load_include(fi)
  File "/usr/lib/python2.7/site-packages/apparmor/aa.py", line 4144, in load_include
    incdata = parse_profile_data(data, incfile, True)
  File "/usr/lib/python2.7/site-packages/apparmor/aa.py", line 2821, in parse_profile_data
    load_include(include_name)
  File "/usr/lib/python2.7/site-packages/apparmor/aa.py", line 4144, in load_include
    incdata = parse_profile_data(data, incfile, True)
  File "/usr/lib/python2.7/site-packages/apparmor/aa.py", line 2831, in parse_profile_data
    profile_data[profile][hat]['network'].add(NetworkRule.parse(line))
  File "/usr/lib/python2.7/site-packages/apparmor/rule/__init__.py", line 73, in parse
    rule = cls._parse(raw_rule)
  File "/usr/lib/python2.7/site-packages/apparmor/rule/network.py", line 129, in _parse
    audit=audit, deny=deny, allow_keyword=allow_keyword, comment=comment)
  File "/usr/lib/python2.7/site-packages/apparmor/rule/network.py", line 76, in __init__
    raise AppArmorBug('Passed unknown object to NetworkRule: %s' % str(domain))
AppArmorBug: Passed unknown object to NetworkRule: inet

An unexpected error occoured!

[Christian Boltz (cboltz)]

This is a known problem with python2 - workaround: use python3 ;-)

To get it working with python3,
    export PYTHON=/usr/bin/python3
and then compile everything again (run configure; make; make install for libapparmor and the utils).

You'll probably also need to change the shebang line of aa-* to python3 - the fastest way to do this is
    for file in utils/aa-* ; do
        sed -i '1s,^#! /usr/bin/env python$,#! /usr/bin/env python3,' "$file"
    done

That said: We are thinking about dropping support for python2, which would mean supporting only python3. Would this be ok for you, or do you have a good reason for using python 2 (except "it's the default")? ;-)

[Hans Kristian Rosbach (hk-8)]

I saw Python 2.7 was supposed to be supported, so I didn't realize that could be the problem.

Python3 is not officially packaged for RHEL 7, but there are a few packages in the unofficial EPEL repo [1].
Looks like only the core python packages are available though, so I am unsure whether there might be missing dependencies.

Dropping support for Python 2.7 would require me to do some changes to our buildsystem and
would require adding another repo to each server. So I would of course prefer Python 2.7 to be
supported. But I would be able to make those changes if required, others might feel that would
raise the bar for using apparmor.

The switch from Perl to Python is something I considered a very good thing, since I do a fair bit of
Python programming at work. This enabled me to inspect the code and possibly fix things myself,
but since we have no systems running Python 3.x yet, I have no actual experience with it yet
(Fedora only just changed its default to Python3, so RHEL 8 will likely finally do the switch,
but that is probably several years out. A future RHEL7.x release probably will have Python3 as
an optional tech preview, with very minimal support/updates).

Btw, I wish you guys were using GitHub or similar, the ease of forking and creating pull requests
is a really strong motivator to follow upstream closely and contribute back. Currently I have some
small changes I have considered contributing, but it keeps getting postponed due to the effort
(however small) involved. Just browsing the code and commitlog here is a bit painful unfortunately.
I realize a switch is not likely to happen, but there you have my thoughts ;)

[1] https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/letter_p.group.html

[Christian Boltz (cboltz)]

Well, 2.10 officially has support for python 2 - it's just a bug that went in unnoticed. We noticed this a while after the release when a newly added test brought it up, but you are the first who actually hit that bug in the wild ;-)

If you are interested in technical details:
type(u'foo') is 'unicode' in py2, but 'str' in py3 - so we'll need to allow both. To make things more interesting, the type 'unicode' no longer exists in py3, so we also need to check for sys.version_info[0] before we can check for type 'unicode' :-/
Since we do this check at varios places in apparmor.rule.*, this will probably become a is_string() helper function.

You are also the first with a distribution that does not (officially) contain python 3, which sounds like a good reason to fix this bug and keep python 2 support for a while. We'll discuss this in the next IRC meeting (Nov 17, see http://wiki.apparmor.net/index.php/MeetingAgenda) - feel free to join that meeting.

For contributing small changes, IMHO the easiest way is to do a bzr checkout, do the changes there and send the "bzr diff" output to the mailinglist (or to the bugtracker, if you prefer that way). bzr also supports branches and merge requests.

[Christian Boltz (cboltz)]

Patch sent to the mailinglist. If you want to check or use it, see https://lists.ubuntu.com/archives/apparmor/2015-November/008872.html

On a more general note - we decided to support python2 on a best-effort base and will officially deprecate it in one of the next major releases (maybe already for 2.11, depending on how much trouble it causes ;-)

[Christian Boltz (cboltz)]

Fixed in trunk r3307 and 2.10 branch r3290.