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.
** Changed in: apparmor (Ubuntu)
Status: New => Triaged
** Changed in: apparmor (Ubuntu)
Importance: Undecided => Medium
** Also affects: apparmor
Importance: Undecided
Status: New
** Changed in: apparmor
Status: New => Triaged
** Changed in: apparmor
Importance: Undecided => Medium
** Tags added: jaunty karmic maverick
--
pam_apparmor fails to hunt through the hats
https://bugs.launchpad.net/bugs/619521
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
