Comment 28 for bug 131976

This seems to have regressed in karmic recently (it still worked in alpha-5 at least). Now we ship quite a fair bunch of apparmor profiles, and none work on the live system:

[ 315.217585] type=1503 audit(1253718188.795:69): operation="open" pid=4505 parent=4504 profile="/usr/sbin/cupsd" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/rofs/usr/lib/libcups.so.2"
[ 420.625182] __ratelimit: 9 callbacks suppressed
[ 420.625187] type=1503 audit(1253718294.203:73): operation="open" pid=4611 parent=2801 profile="/sbin/dhclient3" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/cow/etc/ld.so.cache"
[ 420.625242] type=1503 audit(1253718294.203:74): operation="open" pid=4611 parent=2801 profile="/sbin/dhclient3" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/rofs/lib/libc-2.10.1.so"

to give some examples. In other words, you can't even get on the network due to those.

So we either need a workaround again (like telling casper to disable apparmor on the live system), or a workaround in some generic apparmor rules to allow /cow/ and /rofs/ (this can be set by casper as well), or a fix in apparmor to not expose the underlying file system.

Is it possible that this change

apparmor (2.3.1+1403-0ubuntu21) karmic; urgency=low

  * debian/apparmor.{init-bottom,functions,initramfs}: perform initial
    apparmor rule loading in initramfs.

 -- Kees Cook <email address hidden> Mon, 21 Sep 2009 14:16:26 -0700

somehow triggered this regression? I really doubt that a breakage this large (not being able to get online) would have gone unnoticed in alpha-6, and I tested both i386/amd64 alpha-6 myself (dhcp worked just fine, I didn't test cups). Now I get it with the current amd64 live system on real iron, and with the i386 one in kvm.