apparmor.common.AppArmorBug: exec permissions requested for foobar, but mode is {'x'} instead of exec. This should not happen - please open a bugreport!

[L29Ah]

∞ aa-logprof -m 1566678483.715:202
Reading log entries from /var/log/audit/audit.log.
Updating AppArmor profiles in /etc/apparmor.d.
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.6/aa-logprof", line 56, in <module>
    apparmor.do_logprof_pass(logmark)
  File "/usr/lib64/python3.6/site-packages/apparmor/aa.py", line 1824, in do_logprof_pass
    handle_children('', '', root)
  File "/usr/lib64/python3.6/site-packages/apparmor/aa.py", line 1057, in handle_children
    raise AppArmorBug('exec permissions requested for %(exec_target)s, but mode is %(mode)s instead of exec. This should not happen - please open a bugreport!' % {'exec_target': exec_target, 'mode':mode})
apparmor.common.AppArmorBug: exec permissions requested for /home/l29ah/projects/rustorion/target/debug/build/proc-macro2-0d62d90a89317e13/build-script-build, but mode is {'x'} instead of exec. This should not happen - please open a bugreport!

An unexpected error occoured!

[Christian Boltz (cboltz)]

Do you still have the audit.log that triggers this? If yes, can you please attach it? (If you don't want to attach the full log, the relevant lines for "...//proc-macro2-0d62d90a89317e13/build-script-build" might be enough, but in this case please test if they are enough to reproduce this bug using "aa-logprof -f the_shortened_audit.log")

Looking at the code, I'm quite sure that typ == 'path' because that's the only way how you could reach this code section, but I'm surprised that you get an exec event for 'path'.

As a sidenote: This part of the code was completely rewritten in latest master, so this bug likely "only" affects the 2.11, 2.12 and 2.13 branches - or at least affects master in a different way ;-)

[John Johansen (jjohansen)]

Can you please also include your kernel version (uname -a), distro release/version and apparmor version (apparmor_parser -V)

[L29Ah (zl29ah)]

Linux l29ah-x201 5.1.18+ #126 SMP PREEMPT Tue Jul 30 05:42:38 MSK 2019 x86_64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz GenuineIntel GNU/Linux
Gentoo
AppArmor parser version 2.13.3

[Christian Boltz (cboltz)]

operation="link" [...] requested_mask="x" denied_mask="x" [...] is indeed unexpected - I've never seen an exec event for "link" before.

For the records: this also causes an exception in master, but with a slightly more useful error message (including the log line that causes the exception).

John, does this qualify as a kernel bug, or should I adjust the tools to accept this as a valid exec event?

[L29Ah (zl29ah)]

aa-logprof moves "link …" rules up and apparmor is unhappy with them occuring before the execute rules so i can't even continue using aa-logprof after adjusting the profile manually.