[pkg-apparmor] Bug#805145: Bug#805145: /usr/sbin/aa-status: aa-status --enabled hangs on upgrade until kill

[Christian Boltz]

Hello,

the crash log contains a very interesting detail - you killed aa-status 
while it worked on the profile
    /usr/bin/python2.7//null-5ec//null-5ed//null-5...5ef//null-667//null-668//null-574fe 
(the line was shortened when python created the crash log, there were 
probably more null-* nesting levels)

Those null-* profiles are used in complain mode to track exec events.
In your case, there must have been *lots of* exec events, which leads to 
*lots of* those null-* profiles, nested as deep as the exec chain goes.

Please provide the output of
    wc -l /sys/kernel/security/apparmor/profiles
    time aa-status   # be patient, please ;-)

I'm quite sure aa-status is _not_ in an endless loop - it's "just" busy 
with reading a very long list of profiles.

That said - we are probably wasting CPU cycles if you only check for 
--enabled. That's not really noticable with 50 or 100 profiles loaded, 
but with > 1000 profiles (in your case mostly null-*) it might take some 
time. 
I opened https://bugs.launchpad.net/apparmor/+bug/1516400 for that.


BTW: Do you really have a profile for /usr/bin/python2.7? That's probably 
a bad idea ;-) and I seriously recommend to delete and unload it (unless 
you have a _very good_ reason for what you are doing).

The usual recommendation is to create a profile for the python scripts, 
and then have an ix (inherit) rule for the python interpreter. (This 
also means you have to run those scripts using "./myscript.py", not 
"python myscript.py".)


Regards,

Christian Boltz
-- 
So we have unequivocal proof that I'm more dangerous to my own machine
than any of the updates we've rolled out to Tumbleweed in the last 14
months. [Richard Brown in opensuse-factory]