Comment 6 for bug 204042

Ok, so apparmor doesn't like some local condition on my machine. The substance of my bug report is still the same.

The package maintainer should configure the apparmor package so that it does these things:

- at the pre-install phase, check for affected services and warn the admin when a service doesn't meet the conditions required by the package. Consider bailing out of the install at this stage, if possible/appropriate.
- attempt to ensure, at the install phase, that all conditions are met, or if this is not possible, at least ensure that a running service isn't crippled, for example by automating the step to put apparmor into 'complain mode' for that service.
- check at the post-install phase that all conditions were, in fact, met and if not, warn the admin.

If the package maintainer doesn't do this, the admin has to spend time figuring out that:

- a new kind of kernel message in the syslog is caused by a new package (apparmor).
- apparmor is writing these messages because some of its defaults for a service profile do not match what is on the system.
- apparmor is denying access to file/s essential for a service to start.
- a default 'apparmor profile' must be updated somehow, to accommodate the state of the system (I didn't get this far before I purged apparmor).

Since the preconditions for file access are known by the package maintainer, why can't the package check these things?

Anyhow, thanks for the information about apparmor. It looks as though it might be a very useful security tool, but I would want to read about it in depth and consider the impact very carefully before running it on a production box.

All the best,

--Robin