Comment 2 for bug 1865450

AppArmor does not currently cache denials except an extremely limited dedup for capabilities. Currently apparmor is relying on the audit subsystems rate limiting for it logging which you have rightly noted is insufficient.

AppArmor will continue to report a denial for the error until the profile is reloaded. genprof/logprof should do this when you save but I am pretty sure that is not happening in this case, given the other errors you are seeing.

You can manually reload the profile by doing

  sudo apparmor_parser -r /path/to/profile_name

A better apparmor specific dedup cache is in development but it won't land upstream until the 5.7 or 5.8 kernels.

As for the permission error, I am not sure what is going on but it appears that part of the problem is that the tools are not configured correctly. They are looking /etc/apparmor.d and not finding what they are looking for

  > Profile for /etc/apparmor.d/abstractions not found, skipping
  > Profile for /etc/apparmor.d/apache2.d not found, skipping
  > Setting /etc/apparmor.d/bin.ping to complain mode.
  > Profile for /etc/apparmor.d/cache not found, skipping
  > Profile for /etc/apparmor.d/disable not found, skipping

I know debian has the cache configured to /var/cache/apparmor so looking in /etc/apparmor.d for the cache is not right.

The failure to create the tmp file as root is interesting. How is your /etc/ mounted?