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

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")? ;-)

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

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.

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 ;-)

Fixed in trunk r3307 and 2.10 branch r3290.