Comment 2 for bug 619521

I have reproduced this issue on lucid; it's due to the aa_change_hat(2) call returning -ENOENT when the passed hat doesn't exist, rather than -EPERM or -EACCES that pam_apparmor expects for this situation; instead it treats it as unknown kernel error and aborts. According to John Johanson, this has been the behavior of the kernel portion of apparmor going back to jaunty (and continuing forward in maverick).

It seems to me the right approach to fix this is to teach pam_apparmor the new(er) behavior of the kernel, which ought to be a relatively simple change:

=== modified file 'changehat/pam_apparmor/pam_apparmor.c'
--- changehat/pam_apparmor/pam_apparmor.c 2007-03-13 16:52:28 +0000
+++ changehat/pam_apparmor/pam_apparmor.c 2010-08-19 09:00:23 +0000
@@ -167,6 +167,7 @@
                        break;
                case EPERM: /* Disable when ECHILD patch gets accepted */
                case EACCES:
+ case ENOENT:
                        /* failed to change into attempted hat, so we'll
                         * jump back out and try the next one */
                        break;

though for apparmor trunk the EPERM case ought to go away.

I note that this is not an issue for the apache2 mod_apparmor, as it continues trying hats in the face of any error returned by the kernel.