Dear Maintainer,

Evince currently fails to start on my testing system:
(org.gnome.Evince:10136): Gtk-WARNING **: 15:13:54.895: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/gnome/48x48/status/image-missing.png: Could not spawn `"bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib64" "/lib64" "--symlink" "/usr/lib" "/lib" "--seccomp" "22" "/usr/libexec/glycin-loaders/2+/glycin-image-rs" "--dbus-fd" "21"`: Permission denied (os error 13) (gdk-pixbuf-error-quark, 0)
Bail out! Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/gnome/48x48/status/image-missing.png: Could not spawn `"bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib64" "/lib64" "--symlink" "/usr/lib" "/lib" "--seccomp" "22" "/usr/libexec/glycin-loaders/2+/glycin-image-rs" "--dbus-fd" "21"`: Permission denied (os error 13) (gdk-pixbuf-error-quark, 0)


This is similar to #1127710 and relates to what's mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127710#19

Subsequent bug's messages may suggest a workaround
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127710#24), but
haven't tested this yet.

AFAIU, #1127158 may be the root cause, but is is beyond my
understanding.

Hope this helps,

Best regards,

Olivier Berger <olivier.berger@telecom-sudparis.eu> writes:
/etc/apparmor.d/usr.bin.evince' as root, helped workaround the issue.

Before, syslog reported:
2026-02-14T15:20:52.426038+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.420:237): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11116 comm="blocking-2" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.426048+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.420:238): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11116 comm="blocking-2" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.426049+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.420:239): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11118 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.426049+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.420:240): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11118 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.438040+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.432:241): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11121 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.438048+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.432:242): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11121 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.442046+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.436:243): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11123 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
2026-02-14T15:20:52.442059+01:00 xxxxxxxxxxx kernel: audit: type=1400 audit(1771078852.436:244): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=11123 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

After, evince, starts and just spits:
WARNING: Glycin running without sandbox.
WARNING: Glycin running without sandbox.
WARNING: Glycin running without sandbox.

Not adding Control instructions, fearing I'd be doing it wrong.

Best regards,

FYI, I filed a bug for Evince (see #1127935) for tracking the specific issue in evince.

And your workaround worked.

Many thanks Frederic.

Best regards,

Le Thu, Feb 12, 2026 at 05:09:16PM +0100, Frederic Peters a écrit :

Version: 49~alpha-2
...
are going to need changes to their AppArmor profiles now that gdk-pixbuf
uses glycin. I retitled the bug and raised the severity to grave.

The newer version of evince (which uses GTK 4) does start successfully:
the AppArmor profile doesn't seem to have changed significantly, so
presumably there's been some other code change that makes it not rely so
heavily on gdk-pixbuf.

     smcv

I encourage people to try out papers. The GNOME project switched its
recommendation from evince to papers several months ago.

Thank you,
Jeremy Bícha

retitle 1127935 evince: AppArmor profile doesn't allow running bwrap
severity 1127935 serious
thanks

While the crash is indeed gone as a by-product of 49~alpha-2, the
fallout from the glycin transition as it relates to the AppArmor profile
is still there:

When opening evince, without opening a particular file (just the main
screen) I get 64 of these warnings, one for every recent document:
  ** (evince:49238): WARNING **: 19:21:12.499: Failed to save thumbnail file file:///...: Could not spawn `"bwrap" "--unshare-all" ... --seccomp" "89" "/usr/libexec/glycin-loaders/2+/glycin-image-rs" "--dbus-fd" "87"`: Permission denied (os error 13)

Thanks,
Faidon

Control: reopen 1127935
...
for an AppArmor profile to be overly sensitive to implementation
details, such as whether gdk-pixbuf loads/saves files directly or in a
sandboxed helper. This is certainly a bug in the profile, whether RC or
not.

If you want to repurpose this bug report to track that, to be useful for
that purpose it will need to be reopened; doing that now.

I'm not convinced this is a serious Policy violation, but I'll let
someone more involved with evince maintenance make that decision.

     smcv

Control: affects -1 + src:gdk-pixbuf src:papers src:apparmor
https://salsa.debian.org/gnome-team/extras/evince/-/merge_requests/10
(which is probably both too permissive and too strict, but it does allow
evince to start up).

As a hint for testing, the reproducer that Faidon mentioned will only
work if at least one of your recent documents has not been thumbnailed.
Deleting ~/.cache/thumbnails before running evince is a brute-force way
to make sure that the code paths that use glycin will actually run.

Any package that has a non-trivial AppArmor profile and uses gdk-pixbuf,
such as papers, will need something similar. Perhaps the AppArmor team
could help to generalize this into something that isn't a sandbox
escape, and doesn't require something this extensive in every affected
package?

(I do find myself wondering whether the AppArmor profiles for evince and
papers actually protect us against anything: they allow enough things
that I imagine there's probably at least one sandbox escape available
already. Identifying and isolating the particularly high-risk parts,
like glycin does, or isolating entire apps, like Flatpak does, are
probably better ways in the long term.)

     smcv

Hi,

Simon McVittie (2026-02-20):

If we determine it's worth the effort (#1128767), yes, I'm happy to
help (which could include trying to pull more skilled people and
coordinating the work).

A good next step could be to check if we have affected packages whose
policy is useful enough to be worth the effort. I'm adding this to my
list. Either I find time for it tomorrow or it'll have to wait until
mid-March, so help is welcome.

+1

Cheers,

Simon McVittie (2026-02-20):

I'm not convinced either:

 - With Evince 49 (currently in sid), AFAICT the only problems this
   bug causes are:

    - lots of noise in the Journal; I would say it's a minor regression

    - lack of security improvements brought by a gdk-pixbuf upload to
      sid a few weeks ago; it's sad, but it is not a regression, as
      Evince users in Debian have never had this available and working
      so far

 - This bug being RC and marked as affecting all current versions
   means apt-listbugs currently discourages some users from upgrading
   from a crashing version (48.1) to a working version (49).
   I can't see how this helps anyone.

Same here.

Cheers,

I believe the main problem is that thumbnails are not saved/cached but
instead regenerated on every launch - which is both I/O + CPU intensive,
and also makes for a poor experience (I see a placeholder image on all
thumbnails, until all thumbnails are regenerated).

Note that in contrast to Simon, for me this happens on every run, for
every thumbnail. I don't need to clear old thumbnails for the issue to
manifest. Even after an "aa-complain; evince; aa-enforce; evince" cycle
this is still present and very much a visible difference between the two
runs.

I'm not familiar at all with how apt-listbugs operates :) Given it's the
same bug as the 48.1 crash, and marked in the BTS as affecting both 48.1
and 49, my guess would have been that it would not consider it a
regression... If it isn't, you're right, that's not helpful at all!

Same here. I downgraded from grave, but I felt it is too much of a
regression to be "just" important. It also felt to me like the original
crashing bug was "accidentally" fixed with 49, rather than addressing it
at its root cause (= the glycin+AppArmor incompatibility), so it felt
wrong to me to ignore it just because the most obvious crashes were
gone.

I don't have a strong opinion, though.

Regards,
Faidon

Hey,

Faidon Liambotis (2026-02-25):

Understood, thank you for clarifying this!
to whether the bug affects the currently installed version.

I agree we should not ignore it :)

Cheers,

Hi,

intrigeri (2026-02-24):

Higher work and non-work stuff has kept getting in the way, so I did
not make much progress here; and now I'm going AFK for some time, so
I won't be working on this before early April.

Cheers,

Le Fri, Feb 20, 2026 at 12:53:42PM +0000, Simon McVittie a écrit :

FWIW, papers (aka "Document viewer") is also affected somehow, for instance when trying to save an image present in a PDF, where the brwap permission error pops up.

Hth,

Hi,

I've tried to Cc all interested parties. Please consider trimming down
the list of Cc upon reply, thanks!

Thanks to the work by Aaron Rainbolt, the apparmor.d project, and
multiple other AppArmor contributors, we now have a way to allow an
AppArmor-confined app to use Glycin's bwrap-based sandboxing
mechanism. I understand the chosen approach has some drawbacks which
I don't full understand, but it does seem to work.

To do so, ensure the app's profile has this line:

    include if exists <abstractions/glycin>

On systems that lack this abstraction (e.g. Trixie or older
testing/sid), this will be a no-op.

On systems that do have this abstraction (i.e. apparmor >= 4.1.7-3
which I've just uploaded), this should fix the problem tracked in the
bug reports I've sending this email to. If it doesn't, please let
me know!

I intend to do that work upstream for torbrowser-launcher.
I can't commit to do it for other packages.

Thanks a lot for your patience,

Hi,

I'm taking the example of LibreOffice below, but other apps may
be in the same case. Note that I'm just an end user.

Thanks a lot for the work, but...
that uses Glycin, LibreOffice does *not* use Glycin directly, and
I suppose that it does not even know that Glycin will be used:
here, Glycin is used via the GDK Pixbuf library (a.k.a. gdk-pixbuf).
And perhaps gdk-pixbuf may no longer use Glycin in the future. So it
would be strange if the libreoffice package had to add this line.

So, how should the above line be added? Some kind of double
inclusion (the app's profile → gdk-pixbuf → abstractions/glycin)?
Or some automatic way for Glycin to add such a line to the profiles
of the apps via some kind of mechanism?

Hi,

Am 01.06.26 um 16:36 schrieb Vincent Lefevre:
Exactly.

I would not be opposed to it though if it made the "issue" disappear. But it's indeed not ideal.

Or it being in LibreOffices profile automatically makes it work even  though there's no usage except for using gdk-pixbuf?

No idea.


Regards,


Rene