Hi, Patrick Schleizer wrote (20 Jun 2014 19:32:47 GMT) : > intrigeri: >> Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) : >>> 1) A clean solution, that can be implemented in the grub-common package: >> >>> In /etc/grub.d/10_linux it could be attempted to run aa-status and if it >>> exits 0, the following line >>> [...] >>> could be extended with >>> apparmor=1 security=apparmor > [...] > if [ $? = 3 ]; then > # AppArmor not enabled in kernel. > # Let's enable it. > maybe_apparmor="apparmor=1 security=apparmor" > fi
Ah, OK. That's the part that was not obvious to me in your initial email. Thanks for clarifying. Anyway, let's forget that solution and work on the other :) >> Anyway, I eventually took time to look at how update-grub works, and >> I think I've found a clean solution to this problem: grub-mkconfig >> sources ${sysconfdir}/default/grub.d/*.cfg after sourcing >> ${sysconfdir}/default/grub, so all we have to do is ship >> /etc/default/grub.d/apparmor.cfg, that would inject what we want into >> GRUB_CMDLINE_LINUX. May you please test this? > Requires Debian Jessie. > It works! Great solution! Thanks for trying it! > Shouldn't we use a number in front of the config file such as > /etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make > it simpler for users to overrule it? Yes, ordering requires more thought, and a survey of how other packages that ship snippets into /etc/default/grub.d/ do. Are you up to it? > Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the > apparmor package then please? Once someone has thought through the ordering thing, and the Lintian warning is implemented, I'd personally be happy to provide a patch against the apparmor package that implements this. >> I don't think we want to turn AppArmor on without at least >> *one* conscious decision from the user, > I view "sudo apt-get install apparmor" as my conscious decision and > would expect AppArmor getting enabled. I tend to agree, but that's valid if, and only if, no package gratuitously depend on the apparmor package, which we need to guard against first. >> Maybe a Lintian warning raised when a package depends on >> the apparmor one, and it's not on some whitelist of packages that >> really need to depend on it, would be enough to catch most of these >> problems, though. > Good idea. Are you interested in working on this? At least filing a wishlist bug against Lintian, describing the need, and marking #702030 as blocked by that other bug would be a good start. > I don't understand the need for a whitelist, though. That's > what lintian overrides are for? I would find it inelegant to add such an override in apparmor-{utils,profiles,profiles-extra}. But probably that's merely personal taste, and the Lintian maintainers might feel differently about it. Looking forward to see you take the next steps :) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org