mullvad: disable symlink for non-existing profile

[cboltz]

61939a3bf8732d71088396a7a8b5f73196442b39 creates a disable/mullvad symlink, but (at least on openSUSE Tumbleweed) this profile doesn't exist.

This results in a build failure:

[   20s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink
[   20s] ERROR: link target doesn't exist (neither in build root nor in installed system):
[   20s]   /etc/apparmor.d/disable/mullvad -> ../mullvad

Do you know where the nullvad profile comes from so that I can add that package to BuildRequires?

[curiosityseeker]

Same problem on Arch Linux.

The PKGBUILD for mullvad-vpn-bin contains:

# Symlink apparmor profile to allow Electron sandbox to work
  install -d "$pkgdir/etc/apparmor.d"
  ln -s /opt/Mullvad\ VPN/resources/apparmor_mullvad "$pkgdir/etc/apparmor.d/mullvad"

[roddhjav]

The profile is from https://github.com/mullvad/mullvadvpn-app/blob/main/dist-assets/linux/apparmor_mullvad it was in conflict with the mullvad-gui profile in this project.

Is there an issue when the profile is not installed? I remember having tested this quickly before disabling it.

[cboltz]

It isn't a problem on the AppArmor side (the broken disable/ symlink will be ignored), but the packaging checks catch the broken symlink and error out, which aborts the build.

For now, I adjusted the spec file to delete the disable/mullvad symlink.

[roddhjav]

That is kind of problematic. I need to handle the conflict on apparmor.d's side, or it will fail if someone install Mullvad, but this will also cause an issue on packaging side... Do you know the proper way to fix this?

[cboltz]

I'm afraid there's no sane fix on the packaging side (at least none that I'm aware of) since in nearly all cases (except this one) packaging a broken symlink is a bad idea and a sign for a packaging error.

For now, I have extended the spec file to exclude the disable/mullvad symlink. That fixes the build, but of course also means that this symlink isn't included in the package.

[roddhjav]

The only clean solution I see would be to install the apparmor.d profiles in /usr/share/apparmor.d, and to have a postint script that copy, the profiles in /etc/apparmor.d

I mention this as we will most likely have to move to such an architecture to bypass other issues such as performance.