I ran claude as I have the same problem. Here is its summary:
The snap_browsers child profile in the evince AppArmor profile
(/etc/apparmor.d/usr.bin.evince) does not correctly hand off confinement
to the real snap-confine profile when evince spawns a browser snap (e.g.
Firefox) to open a hyperlink from a PDF. As a result, the whole launch
chain -- including the final browser process itself -- stays trapped
under the very restrictive evince//snap_browsers hat, which lacks the
permissions a modern snap needs to even start. This causes the browser
snap to fail immediately with a dynamic linker error, and no window is
ever opened. Clicking a link in evince silently does nothing from the
user's point of view; the actual error only appears in the terminal that
launched evince (or in the systemd journal / kernel audit log).
STEPS TO REPRODUCE
Ensure Firefox is installed as a snap (snap list firefox), and is the default
web browser (xdg-settings get default-web-browser).
Open any PDF containing a clickable hyperlink in evince (e.g. evince some.pdf).
Click on the hyperlink.
EXPECTED RESULT
The default browser (the Firefox snap) opens the link in a new tab.
ACTUAL RESULT
Nothing visibly happens in evince. If evince was launched from a
terminal, the following error appears there:
/snap/bin/firefox: error while loading shared libraries: libc.so.6:
cannot open shared object file: No such file or directory
Note that the same URL opens correctly via xdg-open <url> run directly
from a terminal, and via a direct D-Bus call to
org.freedesktop.portal.OpenURI.OpenURI from a terminal -- the failure is
specific to the process tree spawned from within evince's own AppArmor-
confined profile.
DIAGNOSIS
journalctl -k shows two AppArmor denials at the moment of the failed
click, both still attributed to the evince child profile even though one
of them has already exec'd into the firefox binary:
apparmor="DENIED" operation="open" class="file"
profile="/usr/bin/evince//snap_browsers"
name="/sys/fs/cgroup/cgroup.controllers"
pid=58434 comm="firefox" requested_mask="r" denied_mask="r"
apparmor="DENIED" operation="open" class="file"
profile="/usr/bin/evince//snap_browsers"
name="/snap/snapd/27710/usr/lib/x86_64-linux-gnu/libc.so.6"
pid=58434 comm="snap" requested_mask="r" denied_mask="r"
The relevant line in /etc/apparmor.d/abstractions/snap_browsers is:
/{,snap/core/[0-9]*/,snap/snapd/[0-9]*/}usr/lib/snapd/snap-confine Pix,
Pix requests a transition to a separate, specifically-named profile for
snap-confine, falling back to inherit the current profile if no matching
profile is loaded. The real snap-confine profiles ARE loaded on this
system (confirmed via aa-status, showing snap-confine.snapd.27710 etc.
as loaded profiles), yet the process never actually leaves the
evince//snap_browsers hat -- the denial log for the firefox process
itself still shows profile="/usr/bin/evince//snap_browsers". This
indicates the Pix transition silently fails to match/apply in this
context, and the entire snap launch (snap-confine -> firefox) is
executed inside the narrow snap_browsers hat instead of transitioning
out to snap-confine's own profile and, from there, to the per-snap
generated profile (snap.firefox.firefox). The snap_browsers hat was
clearly only designed to permit the initial re-exec steps of snap run
<browser>, not a full functional browser launch, so once trapped there
the browser snap cannot even locate its own libc.
I confirmed this is specific to evince's own confinement, and not a
general system issue with the default browser, xdg-desktop-portal, or
snapd, since:
xdg-open <url> from an unconfined terminal shell works.
A manual gdbus call to org.freedesktop.portal.OpenURI.OpenURI from an
unconfined terminal also works.
NoNewPrivs is 0 for the evince process itself, ruling out that common cause of
broken AppArmor domain transitions.
Disabling the evince AppArmor profile entirely (ln -s
/etc/apparmor.d/usr.bin.evince /etc/apparmor.d/disable/ + apparmor_parser -R)
immediately and reliably fixes the issue: links clicked in evince then open
correctly in Firefox.
WORKAROUND CURRENTLY IN USE
Disabling the evince-specific AppArmor profile (not AppArmor as a
whole):
sudo ln -s /etc/apparmor.d/usr.bin.evince /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.bin.evince
This is acceptable in my case since the profile's own header comment
already states confinement is only partial hardening ("complete
confinement is not possible"), but it does fully disable whatever
hardening the profile did provide, which is not a proper fix.
RELATED / POSSIBLY CONTRIBUTING ISSUE
While investigating, I also found that /etc/apparmor.d/usr.bin.firefox-
esr (currently disabled on this system, but still parsed/cached
alongside other profiles) contains:
#include <abstractions/ubuntu-browsers.d/firefox>
with no if exists guard, yet this file does not exist by default on a
system where Firefox is installed purely as a snap (i.e. the
transitional firefox package is installed, but does not ship
/etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox -- only ubuntu-
browsers.d/firefox-esr is shipped, by the firefox-esr package). This
causes apparmor_parser to fail with:
ERROR: Include file /etc/apparmor.d/abstractions/ubuntu-
browsers.d/firefox not found
when attempting to reload any profile while this broken include is
present in the profile set (even though the offending profile itself is
disabled), which complicates debugging/reloading other profiles such as
evince's. I am not certain whether this contributed to the main issue
above, but it should probably be fixed independently (either by guarding
the include with if exists, or by having the firefox transitional
package ship that abstraction file).
SYSTEM INFORMATION
Ubuntu 24.04
apparmor 4.0.1really4.0.1-0ubuntu0.24.04.7
Firefox installed as snap (snap firefox package), transitional firefox deb also
installed
Desktop: GNOME (xdg-desktop-portal-gnome active)
evince launched both from terminal and from file manager -- behaviour identical
in both cases (rules out login-shell environment pollution, LD_LIBRARY_PATH,
NoNewPrivs, etc., all of which were checked and ruled out during diagnosis)
** Changed in: evince (Ubuntu)
Status: Invalid => New
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/208209
Title:
when clicking a URL link in Evince, it hangs
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/208209/+subscriptions
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
