The verification of the Stable Release Update for apparmor has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1324154 Title: aa-logprof is trying to process a binary instead of the profile attached to the binary Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Bug description: [impact] This bug makes it difficult for trusty users to use the apparmor policy utilities. [steps to reproduce] See below [regression potential] This issue is being addressed by updating the python utilities to the version in apparmor 2.9.2 as tracked in bug 1449769. This represents are large change which would normally be risky; however, these changes are isolated to the python utils (so no changes to the policy parser/loader or enforcement), there are a large number of bugs that exist in the trusty version that make using the tools difficult, so it would be difficult to regress further, and the updated version includes many new unit tests to try to prevent from regressions from occurring. [additional info] The python utils testsuite is run as part of the test-apparmor.py test script in lp:qa-regression-testing. The test-apparmor.py also has additional basic usage tests to ensure that basic functionality is maintained. These tests are run as part of the process fro each kernel update. [original description] 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1324154/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
