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:
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.
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.
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(125371818 8.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" 4.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" 4.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"
[ 420.625182] __ratelimit: 9 callbacks suppressed
[ 420.625187] type=1503 audit(125371829
[ 420.625242] type=1503 audit(125371829
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.