Conflicting files after upgrade to apparmor 4

[Stoppedpuma]

ERROR: Conflicting profiles for brave defined in two files:

• /etc/apparmor.d/brave
• /etc/apparmor.d/brave.apparmor.d

[Jeff-WuYo]

steam also

error: failed to commit transaction (conflicting files)
apparmor.d: /etc/apparmor.d/steam exists in filesystem (owned by apparmor)

[roddhjav]

@Stoppedpuma How did you installed the package? this conflict is already automatically managed (/etc/apparmor.d/brave get disabled). Rebuild the package and it will work.

@Jeff-WuYo steam is not installed by default, therefore the conflict is not handled by default. Add steam to dists/overwrite and build the package again and it will work.

[Stoppedpuma]

@Stoppedpuma How did you installed the package? this conflict is already automatically managed (/etc/apparmor.d/brave get disabled). Rebuild the package and it will work.

I'm installing the AUR package. I found out why this happens though, apparmor.d seems to soft lock itself upon aa-enforce /etc/apparmor.d/* which is what I run and just set a few problematic programs in complain with aa-complain /etc/apparmor.d/nameofapplication. This no longer works correctly and will soft lock apparmor.d by preventing you from enforcing, complaining, disabling, etc profiles if one of the conflict profiles is loaded.

[roddhjav]

But, the conflict profile should not be loaded. You should have the following that explicitly disable it: /etc/apparmor.d/disable/brave -> ../brave

It is possibly an issue with aa-enforce that cannot handle this properly.

[Stoppedpuma]

In-case this wasn't obvious, all profiles ending in apparmor.d are affected by this.

[valoq]

Upgrading apparmor to version 4.0.3 on arch resulted in sililar issues, reporting file conflicts with the following:

/etc/apparmor.d/firefox
/etc/apparmor.d/chrome
/etc/apparmor.d/chromium

To resolve the conflict and allow a successful upgrade I had to remove the listed files.

It seems the default apparmor package now contains several profiles that include the new userns permission and nothing else.

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"


abi <abi/4.0>,
include <tunables/global>

profile firefox /{usr/lib/firefox{,-esr,-beta,-devedition,-nightly},opt/firefox}/firefox{,-esr,-bin} flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/firefox>
}

[roddhjav]

@valoq This is different from the initial issue (that concern aa-enforce). Simply update apparmor.d and it will be handled correctlt (see #560)

[roddhjav]

@Stoppedpuma It seems the link that is generated to disable brave (from upstream) is not active anymore. While I fix this, you can simply create it manually:

cd /etc/apparmor.d/disable
sudo ln -s ../brave brave

Then, the aa tools will work again.