Comment 0 for bug 1324154

I am trying to profile apache2 with aa-logprof. As part of that I ran into the following problem

root@tim-X220:~# aa-logprof -m LOGMARK1
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Traceback (most recent call last):
  File "/usr/sbin/aa-logprof", line 52, in <module>
    apparmor.do_logprof_pass(logmark)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2262, in do_logprof_pass
    handle_children('', '', root)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 1237, in handle_children
    sev_db.load_variables(profile)
  File "/usr/lib/python3/dist-packages/apparmor/severity.py", line 180, in load_variables
    for line in f_in:
  File "/usr/lib/python3.4/codecs.py", line 704, in __next__
    return next(self.reader)
  File "/usr/lib/python3.4/codecs.py", line 635, in __next__
    line = self.readline()
  File "/usr/lib/python3.4/codecs.py", line 548, in readline
    data = self.read(readsize, firstline=True)
  File "/usr/lib/python3.4/codecs.py", line 494, in read
    newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc6 in position 24: invalid continuation byte

When I trace back I find that on line 1237 the path to binary is passed to "load_variables" when it expects the path to the profile related to a binary. As a result it opens the binary and tries to process it as a profile. I suspect this but will appear as a range of Unicode style errors depending on what executable is being passed.

The fix is fairly simple. On line 1237 change
   sev_db.load_variables(profile)
to
  sev_db.load_variables(get_profile_filename(profile))

Attached is a patch for this.