Apparmor blocking the opening of Slack

snap
1

As the title suggests for some reason apparmor is blocking slack from opening, however I do not have this problem with other packages such as discord and spotify.

Mar 21 16:50:14 Emiel-pop-os systemd[3183]: Started Application launched by gnome-shell.
Mar 21 16:50:14 Emiel-pop-os systemd[3183]: Started snap.slack.slack.54639468-0145-427f-a2b9-9be7289f068c.scope.
Mar 21 16:50:14 Emiel-pop-os systemd[3183]: app-gnome-slack_slack-18938.scope: Deactivated successfully.
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.535865] audit: type=1400 audit(1647877814.645:439): apparmor="DENIED" operation="capable" profile="/snap/snapd/15177/usr/lib/snapd/snap-confine" pid=18938 comm="snap-confine" capability=12  capname="net_admin"
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.535875] audit: type=1400 audit(1647877814.645:440): apparmor="DENIED" operation="capable" profile="/snap/snapd/15177/usr/lib/snapd/snap-confine" pid=18938 comm="snap-confine" capability=38  capname="perfmon"
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.537138] audit: type=1400 audit(1647877814.649:441): apparmor="DENIED" operation="open" profile="/snap/snapd/15177/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=18938 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.541164] audit: type=1400 audit(1647877814.653:442): apparmor="DENIED" operation="open" profile="snap-update-ns.slack" name="/etc/pop-os/os-release" pid=18964 comm="5" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.545660] audit: type=1400 audit(1647877814.657:443): apparmor="DENIED" operation="open" profile="snap.slack.slack" name="/etc/pop-os/os-release" pid=18938 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.567574] audit: type=1400 audit(1647877814.677:444): apparmor="DENIED" operation="open" profile="snap.slack.slack" name="/etc/pop-os/os-release" pid=18986 comm="snapctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.617177] audit: type=1400 audit(1647877814.729:445): apparmor="DENIED" operation="open" profile="snap.slack.slack" name="/etc/pop-os/os-release" pid=19014 comm="snapctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mar 21 16:50:14 Emiel-pop-os kernel: [  979.689440] audit: type=1326 audit(1647877814.801:446): auid=1000 uid=1000 gid=1000 ses=3 subj==snap.slack.slack (enforce) pid=19025 comm="slack" exe="/snap/slack/60/usr/lib/slack/slack" sig=0 arch=c000003e syscall=330 compat=0 ip=0x7f342aa134e7 code=0x50000
Mar 21 16:50:15 Emiel-pop-os systemd[3183]: snap.slack.slack.54639468-0145-427f-a2b9-9be7289f068c.scope: Deactivated successfully.
2

This is because snap-update-ns reads /etc/os-release to know whether the system is running on an Ubuntu Core or any other kind of Linux distro, and on pop OS specifically, they are not using the standard layout and instead have a symlink in /etc/os-release to point to /etc/pop-os/os-release which is not permitted by AppArmor. This has been discussed elsewhere on the forum, I’m not sure what the appropriate remediation should be for snap-update-ns itself, since it doesn’t use interfaces and so can’t use system-files like some workarounds suggest.

@mborzecki thoughts ?

3

Most distros link that to /usr/lib/os-release. As discussed elsewhere even the manpage mentions that /etc/os-release should be a relative symlink to /usr/lib/os-release, but then it goes to mention that /etc/os-release and /usr/lib/os-release might be symlinks to other files.

If the users feel strongly about using their apps with sandboxing it’s probably best to file a bug in the distro. Alternatively, there’s always --devmode.

1 Like