Evince fails to start because it cannot read .Xauthority

TL,DR: it's Apparmor's fault, and due to my home directory being outside /home.

Under a default installation of Ubuntu 10.04, the apparmor package is pulled in as an indirect Recommends-level dependency of the ubuntu-standard package. The system logs (/var/log/syslog) show that Apparmor is rejecting Evince's attempt to read ~/.Xauthority:

Jul 5 17:58:31 darkstar kernel: [15994724.481599] type=1503 audit(13415 03911.542:168): operation="open" pid=9806 parent=9805 profile="/usr/bin/evince" requested_mask="r::" denied_mask="r::" fsuid=1001 ouid=1001 name="/elsewhere/home/gilles/.Xauthority"

The default Evince configuration for Apparmor (in /etc/apparmor.d/usr.bin.evince) is very permissive: it allows arbitrary reads and writes under all home directories. However, my home directory on this machine is a symbolic link to non-standard location which is not listed in the default AppArmor configuration. Access is allowed under /home, but the real location of my home directory is /elsewhere/home/gilles, so access is denied.

Other applications that might be affected by this issue include:

• Firefox, but its profile is disabled by default (by the presence of a symbolic link /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
• CUPS PDF printing; I haven't tested, but I expect it to fail writing to ~/PDF.

My fix was to edit /etc/apparmor.d/tunables/home.d/local and add the line

@{HOMEDIRS}+=/elsewhere/home/

to have the non-standard location of home directories recognized (note that the final / is important; see the comments in /etc/apparmor.d/tunables/home.d/ubuntu), then run /etc/init.d/apparmor reload to update the Apparmor settings.

If you don't have administrator privileges and the system administrator is unresponsive, you can copy the evince binary to a different location such as ~/bin, and it won't be covered by the Apparmor policy (so you'll be able to start it, but will not be afforded the very limited extra security that Apparmor provides).

This issue has been reported as Ubuntu bug #447292. The resolution handles the case when some users have their home directory as listed in /etc/passwd outside /home, but not cases such as mine where /home/gilles is a symbolic link.

Had the same problem, and your answer pointed me in the right direction. I found a different solution which does not require editing the apparmor configuration. Instead of using a symlink to redirect access to /home, use the bind option on mount. I added the following line to /etc/fstab:

/elsewhere/home /home none bind

Once you do this, apparmor won't even know that directories under /home are "really" located somewhere else, so the complaints will go away.

The advantage of this approach is that it will work for all applications, without having to edit a different apparmor configuration file for each one.