Evince's AppArmor profile prevents opening docs from other apps under Wayland

[Michael Gratton]

Evince fails to run when launched from another app (Nautilus, Ephy, etc) and running under Wayland. For example, nothing appears to happen when double-clicking on a PDF file in Nautilus. Evince is launched, but its Apparmour profile is preventing access to a Wayland socket, hence it immediately exits.

The following is typical of the reported error:

> Oct 19 15:06:40 payens kernel: audit: type=1400 audit(1445227600.333:26): apparmor="DENIED" operation="connect" profile="/usr/bin/evince" name="/run/user/1000/wayland-0" pid=12956 comm="evince" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

Adding the following lines to it's local Apparmour config and reloading Apparmour fixes the problem:

> owner /run/user/*/wayland-* rw,
> owner /run/user/*/weston-shared-* rw,

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: evince 3.16.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Oct 19 17:49:19 2015
InstallationDate: Installed on 2015-07-22 (89 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: evince
UpgradeStatus: Upgraded to wily on 2015-08-27 (52 days ago)

[Christian Boltz (cboltz)]

/run/user/1000/wayland-0 doesn't sound like an Evince-specific thing. Would it make sense to add it to the X abstraction instead? (restricting it to "owner" probably makes sense)

[Michael Gratton (mjog)]

I don't think it is Evince-specific either, but that was the only app that I encountered having the issue. It's definitely not X related however since this is Wayland-specific. The "wayland-0" socket naming convention seems to come from libwayland-server, so maybe that's a reasonable package to provide a Wayland abstraction, but then that needs to be included in the Apparmour profiles for GUI programs.

Note also that the socket name may change depending on the server implementation or at runtime via the WAYLAND_DISPLAY environment variable (which works much in the same way as DISPLAY does for X), if that does happen then the same problem will occur. I don't know how to fix that in Apparmour though.

[Jamie Strandboge (jdstrand)]

I suggest adding a wayland abstraction to apparmor like we currently have for X and mir. Then the evince profile would use '#include <abstractions/wayland>'.

[Christian Boltz (cboltz)]

While I understand the reason to have a wayland abstraction (yes, wayland != X), this probably also means we'll need to change all profiles that include abstractions/X to also include the wayland abstraction. That's also the reason why I proposed (ab)using abstractions/X - that would mean we don't need to modify lots of profiles.

[Jamie Strandboge (jdstrand)]

I'm opposed to this for upstream because X != wayland != mir and it is perfectly reasonable for a policy author to not want X when using mir or wayland, for example. I think it would be better to add mir and wayland to the kde and gnome abstractions instead. These already include X so it makes sense that if they also work under an alternate display server, they should include those server's abstractions.

[Tyler Hicks (tyhicks)]

I'm skipping this change for the 2.11 release because the correct solution is still being discussed between Christian and Jamie.

[Simon McVittie (smcv)]

There is now an <abstractions/wayland>, which is #include'd by <abstractions/gnome>. It includes weston-shared, but not the Wayland socket itself.

I suspect a better rule for that would be:

owner /run/user/*/wayland-[0-9]* rw,

so that the numbered sockets that are conventionally used are matched more precisely.

The complete set of possible fd-passed shared-memory backing files is more like:

owner /run/user/*/{mesa,mutter,sdl,weston,xwayland}-shared-* rw,

because the Wayland code to create an anonymous backing file for shared memory has been copied and pasted all over the place, with some instances changing the name.

[Seth Arnold (seth-arnold)]

Thanks Simon,

Committed revision 3590.

[intrigeri (intrigeri)]

Cherry-picked in Debian's Vcs-Bzr, will be part of the apparmor 2.10.95-7 upload. Thanks everybody!

[intrigeri (intrigeri)]

This was fixed in 2.11.0 so it's fixed in zesty.