apparmor directory

[Clint Byrum]

Excerpts from Clint Byrum's message of Tue Nov 08 06:20:10 -0800 2011:
> Excerpts from Kapil Thangavelu's message of Tue Nov 08 04:38:35 -0800 2011:
> > Excerpts from Gustavo Niemeyer's message of Tue Nov 08 04:51:52 -0500 2011:
> > > Just spotted an exchange in a bug regarding the apparmor directory,
> > > and would like to raise Kapil's comment more generally.
> > > 
> > > Besides the "charm proof" command complaining about the lack of an
> > > "apparmor" directory, the wiki page at
> > > https://juju.ubuntu.com/AppArmor has the following comment:
> > > 
> > > """
> > > If you do not need any profiles, because they are all contained in
> > > packages, you can touch a file in the directory.
> > > 
> > > $ touch apparmor/__NONE
> > > """
> > > 
> > > This feels sub-optimal, both because we never agreed to enforce
> > > apparmor usage, and because the lack of a directory feels like a
> > > cleaner way to convey an optional feature than such a file.
> > 
> > agreed, if its an optional, don't make the user have to think about it.
> > 
> 
> This is a very calculated set of rules, not just something I stumbled
> into.
> 
> I want users to consider the fact that they are not putting an apparmor
> profile in, and I'd like to be able to gather statistics about AppArmor
> usage in the charms. The __NONE file means the person who put it there
> is taking responsibility for saying there's no apparmor needed or that
> the charm wouldn't work with apparmor. An empty dir means that there
> is an opportunity for us to add apparmor to this charm (or assert
> __NONE). Missing dir means that it hasn't even been considered.
> 
> I had considered making the lack of a dir akin to the empty dir now,
> and making an empty dir like __NONE, but this can happen accidentally.
> By enforcing a more rigid structure, the user is pushed toward reading
> the AppArmor policy.
> 

Per a private discussion w/ Gustavo, I've removed all mention of apparmor
from charm proof, and updated the web page a bit to reflect not only that,
but a somewhat simpler method of operation. We can revisit it after we've
actually implemented a few charms w/ support for custom AppArmor rules.