aa-logprof is trying to process a binary instead of the profile attached to the binary
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| apparmor (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| Trusty |
Fix Released
|
Medium
|
Marc Deslauriers | ||
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/
apparmor.
File "/usr/lib/
handle_
File "/usr/lib/
sev_
File "/usr/lib/
for line in f_in:
File "/usr/lib/
return next(self.reader)
File "/usr/lib/
line = self.readline()
File "/usr/lib/
data = self.read(readsize, firstline=True)
File "/usr/lib/
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_
to
sev_db.
Attached is a patch for this.
Related branches
| timdaman (timdaman-gmail) wrote | #1 |
| Ubuntu Foundations Team Bug Bot (crichton) wrote | #2 |
| tags: | added: patch |
| Christian Boltz (cboltz) wrote | #3 |
| Christian Boltz (cboltz) wrote | #4 |
| Changed in apparmor (Ubuntu): | |
| status: | New → Fix Committed |
| Changed in apparmor (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| Changed in apparmor (Ubuntu Trusty): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| assignee: | nobody → Marc Deslauriers (mdeslaur) |
| description: | updated |
| Launchpad Janitor (janitor) wrote | #6 |
| Changed in apparmor (Ubuntu Trusty): | |
| status: | Triaged → Fix Released |
| Adam Conrad (adconrad) wrote Update Released | #7 |
The attachment "profile_
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]