apparmor 2.5, apparmor-parser from bzr; kernel 2.6.33.5 with apparmor 2.5 tarball patch
# service apparmor reload
Przeładowanie usługi apparmor...................................................................................................................[ AKTYWUJĘ ]
/sbin/apparmor_parser: zamiana "HAT_owner_46291" nie powiod?a si?.Brak pami?ci
where in english it means: change "HAT_owner_46291" failed: Out of memory
# free
total used free shared buffers cached
Mem: 6193244 5314312 878932 0 0 1440604
-/+ buffers/cache: 3873708 2319536
I need to kill main application on this server (very busy apache) and then do reload to get it succeed (or simply strace reload process - then it also succeeds).
Previous version (2.3.1286) had no such problem.
I have only one policy - it applies to httpd daemon. That policy contains over 1300 hats and every hat includes the same common hat abstraction file.
Do any of the hats grant privileges to resources that are specific to that hat?
When I hear of 1300 hats all containing identical information, I think perhaps your Apache mod_apparmor needs to be using AAHatName or AADefaultHatName or both in your Apache configuration file. (mod_apparmor(8) for details.)
The idea being that you could have one application, say phpBB served from /phpBB/ and using the phpBB hat, drupal served from /drupal/ using a drupal hat, and four specific cgi files with the URI-generated hats. It doesn't matter how many URIs phpBB and drupal use internally, they should probably be treated as single applications for the purposes of AppArmor. (Just about anything interesting will be needing access to a database, and once you grant access to the database socket, you've granted access for the entire application. So keeping the applications separated will keep your drupal from infecting your phpBB, or more likely the other way around. But keeping phpBB user pages from messing with phpBB admin data will be pretty hard.)
(Of course, 800 megs really does seem like it should be enough memory to compile just about any reasonable policy, and there's another 1.4 gigs that could have been scavenged if it were necessary.)