Comment 8 for bug 556343

Discussed this with the security team and jjohansen. The conclusion re apparmor is:

1. if the profile replacement succeeds, no problem
2. if the profile replacement fails, then the process continues to run under the old profile, logging to kern.log (or audit.log if using auditd)
3. if there are no apparmor denied messages in the logs, the upgrade problem is elsewhere. If there are apparmor denied messages in the logs, it is an apparmor problem

Based on the above, this bug should not be an apparmor problem. However, it did uncover the fact that the new binary and configuration could be blocked by the old profile (but logged, always logged!), and this condition will be reviewed but does not affect this bug.