Recent upgrades have resulted in thunderbird failing to start with the
following errors:

[29117] Sandbox: CanCreateUserNamespace() clone() failure: EACCES
[29117] Wayland Proxy [0x7fe202279bd0] Error: StartProxyServer(): bind() error
: Permission denied
[GFX1-]: FireTestProcess failed: Failed to spawn child process
“/usr/lib/thunderbird/glxtest” (Permission denied)

[GFX1-]: glxtest: ManageChildProcess failed

[GFX1-]: No GPUs detected via PCI

WARNING: Glycin running without sandbox.
[Parent 29117, Main Thread] WARNING: can't init metadata tree
/home/skquinn/.local/share/gvfs-metadata/root: open: Permission denied: 'glib
warning', file toolkit/xre/nsSigHandlers.cpp:201

(thunderbird:29117): GVFS-WARNING **: 01:26:50.272: can't init metadata tree
/home/skquinn/.local/share/gvfs-metadata/root: open: Permission denied
[Parent 29117, Main Thread] WARNING: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.:
'glib warning', file toolkit/xre/nsSigHandlers.cpp:201

(thunderbird:29117): Gtk-WARNING **: 01:26:50.272: Could not load a pixbuf from
icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
WARNING: Glycin running without sandbox.
[Parent 29117, Main Thread] WARNING: can't init metadata tree
/home/skquinn/.local/share/gvfs-metadata/root: open: Permission denied: 'glib
warning', file toolkit/xre/nsSigHandlers.cpp:201

(thunderbird:29117): GVFS-WARNING **: 01:26:50.277: can't init metadata tree
/home/skquinn/.local/share/gvfs-metadata/root: open: Permission denied
**
Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion
failed (error == NULL): Failed to load
/usr/share/icons/Adwaita/scalable/status/image-missing.svg: Could not spawn
`env -i XDG_RUNTIME_DIR="/run/user/3529" "/usr/libexec/glycin-
loaders/2+/glycin-svg" "--dbus-fd" "63"`: 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/Adwaita/scalable/status/image-missing.svg: Could not spawn
`env -i XDG_RUNTIME_DIR="/run/user/3529" "/usr/libexec/glycin-
loaders/2+/glycin-svg" "--dbus-fd" "63"`: Permission denied (os error 13) (gdk-
pixbuf-error-quark, 0)
Redirecting call to abort() to mozalloc_abort

ExceptionHandler::GenerateDump attempting to
generate:/home/skquinn/.thunderbird/hoswq85j.default/minidumps/69a9cf50-0269-4629-620d-9a30cc91f72a.dmp
ExceptionHandler::GenerateDump cloned child 29222
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::GenerateDump minidump generation succeeded
---

I have double-checked file permissions and all seem in order. Changes to make
permissions more liberal have not helped. It is quite possible this isn't a
thunderbird bug per se but this is the only package that has been thusly
affected that I have found.

This is likely triggered by gdk-pixbuf's switch to glycin in Unstable this week.

What desktop are you using?
What version of glycin-loaders do you have installed?
Have you tried restarting your computer?
Have you noticed this issue with any other apps?
Firefox? Loupe?

Is there anything else we should know about your Debian system?

Thank you,
Jeremy Bícha

hi,
(48, from testing) with latest gdk-puxbuf, (running on GNOME from
unstable),

~~~~
(org.gnome.Evince:8501): Gtk-WARNING **: 16:54:33.253: 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/Adwaita/scalable/status/image-missing.svg: 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" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/fred/.cache/fontconfig" "/home/fred/.cache/fontconfig" "--ro-bind-try""/home/fred/.fonts" "/home/fred/.fonts" "--ro-bind-try" "/home/fred/.local/share/fonts" "/home/fred/.local/share/fonts" "--ro-bind-try" "/var/cache/fontconfig" "/var/cache/fontconfig" "--bind-try" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "24" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "23"`: 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/Adwaita/scalable/status/image-missing.svg: 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" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/fred/.cache/fontconfig" "/home/fred/.cache/fontconfig" "--ro-bind-try" "/home/fred/.fonts" "/home/fred/.fonts" "--ro-bind-try" "/home/fred/.local/share/fonts" "/home/fred/.local/share/fonts" "--ro-bind-try" "/var/cache/fontconfig" "/var/cache/fontconfig" "--bind-try" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/fred/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "24" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "23"`: Permission denied (os error 13) (gdk-pixbuf-error-quark, 0)

Aborted
~~~~

evince 49 (from unstable) works fine (but it's been ported to gtk4 so
there are many changes that could explain it).

I'm available for anything that would help debugging this.



         Frederic

I wrote:

Looking further (in my case) it's related to apparmor,

kernel: audit: type=1400 audit(1770913688.152:456): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/evince" name="/usr/bin/bwrap" pid=34166 comm="blocking-2" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Switching evince to complain mode (aa-complain /etc/apparmor.d/usr.bin.evince)
allowed it to start.

Shawn, maybe aa-complain /etc/apparmor.d/usr.bin.thunderbird would fix
it for you? (aa-complain is part of apparmor-utils).


         Frederic

As you said there, I expect it is related to this gdk-pixbuf transition. I agree
that you designate #1127710 as blocking #1127158.

To answer your questions to the OP of #1127710: About firefox on my box, it is not
affected and still works. I don't use Loupe. I also noticed a report that evince seems
affected by this transition and I don't know yet if evince works on my box either
because I don't use it. I also verified the Thunderbird bug exists on my box with Intel
integrated graphics and Raptor Lake CPU on the bare metal, and in both KVM/Qemu
and Xen/Qemu virtual environments, and in all cases the bug appears when
launching Thunderbird in Gnome. Reboot does not help.

As I mentioned in another message to #1127158, I can workaround this bug in
current sid by running Thunderbird under LXQt, presumably because the gdk-pixbuf
transition does not have as many adverse affects on environments based on Qt
instead of GTK. I have not tested other DEs such as KDE Plasma and XFCE. I would
expect XFCE would be more likely to be affected than KDE Plasma because, like
Gnome, it uses GTK.

I do have some skills to try to identify a cause of this bug, but unfortunately not
lots of time and I think it may take some time, but I think there is plenty of time
before Forky is released. Until instructed otherwise, I will send further reports
about this Thunderbird crash I am seeing to #1127710, per your request.

Cheers.

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 :

Control: affects -1 src:apparmor

Thunderbird also works for me with Debian Testing (which now has
gdk-pixbuf+glycin). I see no apparmor denials for Thunderbird. (The
evince issue is https://bugs.debian.org/1127935 and is fixed in
unstable.)

For those affected by this issue, is there something different about
your Thunderbird configuration? Is there some extra addon installed?

Are you using Debian's thunderbird package or is it possible you
installed Thunderbird a different way?

Thank you,
Jeremy Bícha

with Thunderbird on sid after the gdk-pixbuf+glycin transition. The aa-complain
workaround does fix Thunderbird on sid on my box. Thanks, Frederic!

FWIW, here are the related apparmor messages I am getting after setting apparmor
complain mode for Thunderbird, as it relates to glycin loaders:

test@debian:~$ sudo journalctl -b --no-pager | grep audit | grep thunderbird | grep glycin
Feb 14 13:38:31 debian kernel: audit: type=1400 audit(1771094311.887:1074): apparmor="ALLOWED" operation="exec" class="file" profile="thunderbird" name="/usr/libexec/glycin-loaders/2+/glycin-svg" pid=7225 comm="gly-hdl-loader" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 target="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-svg"
Feb 14 13:38:31 debian kernel: audit: type=1400 audit(1771094311.887:1075): apparmor="ALLOWED" operation="file_mmap" class="file" profile="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-svg" name="/usr/libexec/glycin-loaders/2+/glycin-svg" pid=7225 comm="glycin-svg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Feb 14 13:38:31 debian kernel: audit: type=1400 audit(1771094311.887:1076): apparmor="ALLOWED" operation="file_mmap" class="file" profile="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-svg" name="/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2" pid=7225 comm="glycin-svg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Feb 14 13:39:02 debian kernel: audit: type=1400 audit(1771094342.068:1271): apparmor="ALLOWED" operation="signal" class="signal" profile="thunderbird" pid=7085 comm="gly-global-exec" requested_mask="send" denied_mask="send" signal=kill peer="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-image-rs"
Feb 14 13:39:07 debian kernel: audit: type=1400 audit(1771094347.180:1272): apparmor="ALLOWED" operation="signal" class="signal" profile="thunderbird" pid=7085 comm="gly-global-exec" requested_mask="send" denied_mask="send" signal=kill peer="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-svg"
Feb 14 13:42:05 debian kernel: audit: type=1400 audit(1771094525.777:2390): apparmor="ALLOWED" operation="signal" class="signal" profile="thunderbird" pid=8238 comm="gly-global-exec" requested_mask="send" denied_mask="send" signal=kill peer="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-image-rs"
Feb 14 13:42:06 debian kernel: audit: type=1400 audit(1771094526.261:2391): apparmor="ALLOWED" operation="signal" class="signal" profile="thunderbird" pid=8238 comm="gly-global-exec" requested_mask="send" denied_mask="send" signal=kill peer="thunderbird//null-/usr/libexec/glycin-loaders/2+/glycin-svg"
test@debian:~$

Thanks again,

Chuck, a Debian tester

here are the related apparmor messages related to thunderbird (note there is no mention of
glycin in these messages but there are mentions of bwrap):

Feb 14 14:20:13 debian kernel: audit: type=1400 audit(1771096813.204:2392): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="thunderbird" pid=11854 comm="apparmor_parser"
Feb 14 14:20:13 debian kernel: audit: type=1400 audit(1771096813.244:2393): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="thunderbird//browser_java" pid=11854 comm="apparmor_parser"
Feb 14 14:20:13 debian kernel: audit: type=1400 audit(1771096813.260:2394): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="thunderbird//browser_openjdk" pid=11854 comm="apparmor_parser"
Feb 14 14:20:13 debian kernel: audit: type=1400 audit(1771096813.264:2395): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="thunderbird//gpg" pid=11854 comm="apparmor_parser"
Feb 14 14:20:13 debian kernel: audit: type=1400 audit(1771096813.264:2396): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="thunderbird//sanitized_helper" pid=11854 comm="apparmor_parser"
Feb 14 14:20:18 debian kernel: audit: type=1400 audit(1771096818.944:2397): apparmor="DENIED" operation="userns_create" class="namespace" profile="thunderbird" pid=11856 comm="thunderbird" requested="userns_create" denied="userns_create"
Feb 14 14:20:18 debian kernel: audit: type=1400 audit(1771096818.976:2398): apparmor="DENIED" operation="mknod" class="file" profile="thunderbird" name="/run/user/1000/wayland-proxy-11856" pid=11856 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.060:2399): apparmor="DENIED" operation="exec" class="file" profile="thunderbird" name="/usr/lib/thunderbird/glxtest" pid=11876 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.152:2400): apparmor="DENIED" operation="open" class="file" profile="thunderbird" name="/proc/11856/oom_score_adj" pid=11856 comm="thunderbird" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.152:2401): apparmor="DENIED" operation="open" class="file" profile="thunderbird" name="/proc/11856/cgroup" pid=11856 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.208:2402): apparmor="DENIED" operation="open" class="file" profile="thunderbird" name="/sys/devices/virtual/dmi/id/product_name" pid=11856 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.208:2403): apparmor="DENIED" operation="open" class="file" profile="thunderbird" name="/sys/devices/virtual/dmi/id/product_sku" pid=11856 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.348:2404): apparmor="DENIED" operation="file_inherit" class="net" info="failed af match" error=-13 profile="thunderbird//sanitized_helper" pid=11963 comm="bwrap" family="netlink" sock_type="raw" protocol=0 requested_mask="send receive" denied_mask="send receive"
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.348:2405): apparmor="DENIED" operation="open" class="file" info="Failed name lookup - disconnected path" error=-13 profile="thunderbird//sanitized_helper" name="apparmor/.null" pid=11963 comm="bwrap" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
Feb 14 14:20:19 debian kernel: audit: type=1400 audit(1771096819.348:2406): apparmor="DENIED" operation="getattr" class="file" info="Failed name lookup - disconnected path" error=-13 profile="thunderbird//sanitized_helper" name="" pid=11963 comm="bwrap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Cheers

Control: severity -1 important

I figured out why Frederic & I could not reproduce this from a clean
Debian Testing install. Thunderbird includes an apparmor profile but
it has been disabled by default for many years. See this file:

/usr/share/doc/thunderbird/README.apparmor
https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/README.apparmor

It appears like you previously enabled the Thunderbird apparmor
profile. Therefore, although this is clearly a regression, I don't
consider it to be RC since this is a non-default configuration.

Assistance is requested in fixing Thunderbird's apparmor profile.
Recent versions of Ubuntu only provide Thunderbird as a Snap, so this
issue doesn't currently affect Ubuntu.

Thank you,
Jeremy Bícha

Both my sid and my testing apparently had the Thunderbird apparmor profile enabled
because now, after the gdk-pixbuf+glycin transition to testing, Thunderbird now also
needs its apparmor profile set to complain mode for it to launch in both my testing and
sid installations.

I am sure I did not enable the Thunderbird apparmor profile. Something did,
so from my perspective, the only question left for me is, what did enable
the Thunderbird apparmor profile on my boxes? If it was some install
script of some package in the Debian archive, then there could be some
pure Debian installations that do have the Thunderbird apparmor profile
enabled by default. Also, I am not convinced, based on a seven year-old
README file, that every pure Debian installation now, seven years later,
will have the Thunderbird apparmor profile disabled by default.

I would suggest that, until the Thunderbird apparmor profile is fixed, that
the next update to Thunderbird or apparmor check to see it it is enabled,
and if it is, then it should be set to complain mode until the Thunderbird
apparmor profile is fixed.

Cheers.

I don't think there's anything in Debian that re-enabled the profile.
If your install is old enough, maybe it wasn't disabled when the
change in the default happened.

That was done once before. Someone would just need to update the
version number to do it again:
https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/thunderbird.postinst#L72-81

Thank you,
Jeremy Bícha

This is the likely explanation, since both my testing and sid installations date back
to the days when Jessie was the stable version.

Hi,

Am 14.02.26 um 22:51 schrieb Jeremy Bícha:

why it should be enabled now (by default)?
No, there is no other package then apparmor itself that would enable it,
have a look at the modification time of or similar
/etc/apparmor.d/disable/usr.bin.thunderbird so you will know when it was
modified.

Then you (the reporter of that issue) will have for sure experienced
some other issues in the past originated in apparmor. We all agreed many
years back to have the apparmor profile for Icedove/Thunderbird by
default disabled in preparation for the Buster release.

The Thunderbird package will do nothing on this in the future, a user
who has enabled the apparmor package is basically on it's own as
enabling the profile was done manually. That's what the apparmor
maintainers together with the Thunderbird maintainers have agreed on in
the past.
We found strong reasons to have the profile disabled by default. As
nothing has changed in the recent years on this I've set the severity to
important.

Doing a similar thing as done for versions greater then 1:52.5.0-1~
isn't simple as it might look like, turning now the profile off for all
the user that have switched it on isn't a good idea.

A potential fix needs to be done within the Apparmor package as this is
providing also the profile.

A few more small hints can be found on
https://wiki.debian.org/Thunderbird#AppArmor_profile

Am 14.02.26 um 23:23 schrieb Carsten Schoenert:

I'm wrong on this, the profile is shipped by the Thunderbird package.

You might need to add something similar to this within the profile.

glxtest is needed since some versions Thunderbird is able to start.

I am not the reporter of the issue but I am experiencing it now. But you are not correct
to say that I have for sure experienced other issues in the past originated in apparmor
because the apparmor profile for Thunderbird has apparently been enabled
all this time: My sid and testing installations date back to the days when Jessie was the stable
version, and I have never, over those ten plus years experienced any apparmor issue
in either sid or testing in thunderbird or in any other package until this gdk-pixbuf
transition. Something enabled the Thunderbird apparmor profile on my box, but it was
not me as the user that did it. I have never even heard of tools like aa-complain and
aa-enforce until today, and I have used Debian for more than eleven years. How could
I have enabled the apparmor profile if I have never even heard of the tools that are
used to enable it?

I agree, but I am sure I did not enable the apparmor profile, yet somehow it was
enabled on both my sid and testing installations that have had zero apparmor problems
with any package, including Thunderbird, since the time my installations originated
way back when Jessie was the stable version, and I have been very conservative
about changing defaults and have updated frequently and always followed the
Don't break Debian rules. My case might still be a corner case, but this issue
was definitely *not* caused by the user deliberately changing any default apparmor
profile settings on my installations.

Are you sure there was not a bug in the patch to Thunderbird to ensure the apparmor
profile got disabled in preparation for Buster? Maybe, for some reason, on my installations
that date back to the days when Jessie was released, the Thunderbird apparmor profile
did not get disabled. Again, my case might be a corner case that fell through the cracks.

The main point I am trying to get across is there might be other installations out there
like mine that for whatever reason (other than user intervention) the apparmor profile
for Thunderbird is enabled. We haven't yet heard from the reporter of this bug yet
on matters such as how old that installation is or if disabling the apparmor Thunderbird
profile fixes this issue on that installation, or if that user manually enabled the
Thunderbird apparmor profile in that installation. If that user also says no changes to
the apparmor profile were ever made by the user on that installation, then there
would be strong evidence that there is some install/upgrade path that can lead to the
situation where the Thunderbird apparmor profile, for whatever reason, was
left enabled despite previous attempts to disable it by default in Debian packaging.

during upgrade/installation (is that done via the NEWS.Debian file?) that says
something like:

The Thunderbird apparmor profile is intended to be disabled in a default installation.
There is a regression since the gdk-pixbuf+glycin transition that causes Thunderbird
to fail to start if the Thunderbird apparmor profile is enabled in some configurations.
One known configuration where Thunderbird fails to start is when launching
Thunderbird under Gnome and the Thunderbird apparmor profile is enabled.
Therefore, if you have manually enabled the Thunderbird apparmor profile or if
for some other reason the Thunderbird apparmor profile is enabled, it will be
necessary to manually disable the Thunderbird apparmor profile to successfully
launch Thunderbird under Gnome until #1127710 in the BTS is closed.

The file does not exist on my box. Also, since I touched
/etc/apparmor.d/usr.bin.thunderbird today when I changed its
status from "enforce" to "complain" today, it is not easy to tell
when the change happened, if it ever happened.

One of my current up-to-date Trixie (stable) installations has a similar history
that dates back to the Jessie days.

On that current Trixie (stable) installation Thunderbird's apparmor profile is enabled,
the /etc/apparmor.d/disable directory is empty, and the /etc/apparmor.d/disable
directory has not been touched since December 29, 2017, which is also when that
directory was created:

test@trixie:/etc/apparmor.d$ sudo aa-status  --pretty-json | jq .profiles.thunderbird 
"enforce"
test@trixie:/etc/apparmor.d$ ls -l disable
total 0
test@trixie:/etc/apparmor.d$ ls -ltd disable
drwxr-xr-x 2 root root 4096 Dec 29  2017 disable
test@trixie:/etc/apparmor.d$ ls -lctd disable
drwxr-xr-x 2 root root 4096 Dec 29  2017 disable
test@kolbe:/etc/apparmor.d

I don't know why my stable installation did not get its Thunderbird apparmor profile
disabled, but I think this shows that nothing has touched my /etc/apparmor.d/disable
directory since December 29, 2017, which is in the expected time range when
Buster was in development. But it is hard to know why the /etc/apparmor.d/disable
was created on December 29, 2017 and also has not been touched since then.

I don't know if this information is enough to reproduce an upgrade path that
results in a sid or testing installation today that has the Thunderbird apparmor
profile enabled, but I think this data suggests that some upgrade paths exist that
result in a situation where the Thunderbird apparmor profile never gets disabled if
the installation goes back far enough.

Cheers.

One more interesting data point on this Trixie (stable) installation.
The /etc/apparmor.d/usr.bin.thunderbird file was touched on November 23, 2023
and created on November 27, 2023:

test@trixie:/etc/apparmor.d$ ls -lt usr.bin.thunderbird
-rw-r--r-- 1 root root 14547 Nov 23  2023 usr.bin.thunderbird
test@trixie:/etc/apparmor.d$ ls -lct usr.bin.thunderbird
-rw-r--r-- 1 root root 14547 Nov 27  2023 usr.bin.thunderbird
test@trixie:/etc/apparmor.d$

This suggests it is the result of a package update dated Nov 23 2023
that was installed on my box on Nov 27 2023.

Looks like it is the result of this entry from the Thunderbird changelog:

thunderbird (1:115.5.0-1) unstable; urgency=medium

  [ intrigeri ]
  * [a6be3ab] AppArmor: update profile from upstream at commit
              9d3fa88cdab512e45f6fd80f067337f200d356bc

  [ Carsten Schoenert ]
  * [ed61fd6] New upstream version 115.5.0
    Fixed CVE issues in upstream version 115.5 (MFSA 2023-52):
    CVE-2023-6204: Out-of-bound memory access in WebGL2 blitFramebuffer
    CVE-2023-6205: Use-after-free in MessagePort::Entangled
    CVE-2023-6206: Clickjacking permission prompts using the fullscreen
                   transition
    CVE-2023-6207: Use-after-free in ReadableByteStreamQueueEntry::Buffer
    CVE-2023-6208: Using Selection API would copy contents into X11 primary
                   selection.
    CVE-2023-6209: Incorrect parsing of relative URLs starting with "///"
    CVE-2023-6212: Memory safety bugs fixed in Firefox 120, Firefox ESR 115.5,
                   and Thunderbird 115.5

This patch was done on December 26, 2017:

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/81a8c00dc530c7dedf83c9857b227c3c3c164e22

        fi
        # Disable apparmor on new installations and when we're upgrading from
        # a version that had it enabled by default
 -      if test -z "$2" || dpkg --compare-versions "$2" le "1:52.5.0-1~"; then
 +      if test -n "$2" && dpkg --compare-versions "$2" gt "1:52.5.0-1~"; then
 +          :   # Leave the disable/ symlink at users choice if
 +              # upgrading from a version that ships the symlink
 +      else
            mkdir -p /etc/apparmor.d/disable
-           ln -s /etc/apparmor.d/usr.bin.thunderbird  /etc/apparmor.d/disable/usr.bin.thunderbird
+           [ -f /etc/apparmor.d/disable/usr.bin.thunderbird ] || ln -s /etc/apparmor.d/usr.bin.thunderbird  /etc/apparmor.d/disable/usr.bin.thunderbird
        fi
    ;;

My /etc/apparmor.d/disable directory was created three days later, on December 29, 2017,
but it is empty today and it has not been touched since that day it was created. So the
question is: why is the disable/ symlink missing on my installations? Was it ever
created? If not, why not? If we can answer this question, we can explain how
the Thunderbird apparmor profile can remain enabled even if the user never
manually enabled it.

The latest GNOME from unstable/experimental.

2.0.8-1

Yes, this problem has persisted after a restart.

Just Thunderbird.

The only really unusual thing about it is that it began as an Ubuntu install and was cross-upgraded a couple of years ago. I doubt this is related to that based on the other messages I have since received on this bug, however.

After a reboot I was finally able to restart Thunderbird. I took the
drastic step of `rm /etc/apparmor.d/usr.bin.thunderbird` (I have backups
if I need to restore it) as aa-complain said there was a syntax error in
that file. (Or, most likely, it will be reinstalled with a later
version, hopefully with this syntax error fixed.)

That is drastic. I did not see any message from aa-complain saying there was a
syntax error in /etc/apparmor.d/usr.bin.thunderbird but the history of my
installation is Ubuntu-free. I suspect the syntax error is an artifact of that
old Ubuntu installation you upgraded from, so I wouldn't bring back that
file but try to restore the correct, default, Debian one. I am not sure what
the best way to do that is, though. Hopefully Carsten will weigh in with some
advice for you.

I would also check to see if /etc/apparmor.d/disable/usr.bin.thunderbird exists.

If it does not, I would recommend creating it because if you do restore the
correct, Debian version of /etc/apparmor.d/usr.bin.thunderbird either
manually or automatically in some future update, your Thunderbird
will likely be broken again without /etc/apparmor.d/disable/usr.bin.thunderbird
which by default on Debian, AFAICT, should be a symlink to
/etc/apparmor.d/usr.bin.thunderbird which can be created by something like:

$ sudo mkdir -p /etc/apparmor.d/disable
$ sudo ln -s /etc/apparmor.d/usr.bin.thunderbird /etc/apparmor.d/disable/usr.bin.thunderbird

The reason my Thunderbird broke was that the symlink in /etc/apparmor.d/disable
was missing, and I have verified that adding the symlink was an alternate way
to workaround this bug on my box, instead of running aa-complain on
/etc/apparmor.d/usr.bin.thunderbird. I think that is the better way to
workaround the bug if you desire your installation to, as closely as possible,
restore the default Debian installation of Thunderbird, but I could be
wrong and I suggest you should prefer any advice Carsten might have for you
on how best to fix your system since Carsten is the person who has been
maintaining Thunderbird on Debian for a long time, AFAICT.

Cheers.

Actually, what you did is very unusual. Crossgrading from Ubuntu to
Debian is not supported. Ubuntu's thunderbird packaging was managed
completely separately from Debian's and I believe it didn't provide an
apparmor profile. Your situation may not have been handled by Debian's
postinst script.

Thank you,
Jeremy Bícha

Shawn,

I recommend that you make time to do a clean Debian install. Most
packages on your system are probably ok, but there may be a few like
thunderbird where you accidentally have a non-default install which
can lead to unexpected behavior. The problem is that it's not easily
possible to tell which packages are in this unintended state. Backup
your user config and data before doing a new install.

Thank you,
Jeremy Bícha

If it is a symptom of my unusual upgrade path, this is the first major
one. It's been long enough that I almost forgot that this started as an
Ubuntu install many years ago--long enough that any backups of the
original Ubuntu install I may have made are long gone so I can't go back
and check to see what was there.

If that apparmor profile didn't come from the Ubuntu package, then I
don't see how that's a cause of this specific issue.

On 2/15/26 08:24, Jeremy Bícha wrote:> Shawn,

I am noting this advice. However, to be honest, this computer is
probably nearing end-of-life (it originally came with Windows 7, it's on
its second power supply, and that form factor power supply is becoming
increasingly rare, in addition to the usual obsolescence). I expect to
either retire it by the end of 2027 or install some other OS on it
before that date.

Where else could it have come from, if not from some old Ubuntu Thunderbird
package? Perhaps it came from some Ubuntu Thunderbird package dating from
before the time before Ubuntu started delivering Thunderbird in a snap package
instead of a deb package. It is likely modern Debian would find syntax errors in
such an apparmor profile originating on a very old Ubuntu installation. It is also
likely, as Jeremy mentioned in an earlier message, that the Debian postinst script
that was intended to disable the Thunderbird apparmor profile was never executed
on your box or for some other reason the Thunderbird apparmor profile never was
disabled, making your box, like mine, a non-default installation of Thunderbird on
Debian.

Cheers.

The common theme between my box and Shawn's box, the only two systems
so far where this bug has been reported, is that they both are very
old installations with either a long (from pre-Buster) or unusual (Ubuntu)
upgrade path. I suspect that many old installations of Thunderbird on Debian
dating from pre-Buster and upgraded along they way might be affected by this
bug. This may still be a fairly low percentage of all current stable
installations, so I think the downgrade of severity from grave to important
is reasonable.

At the least, I think this bug deserves a mention in Thunderbird's
debian/README.apparmor file which, IIRC, lacks instructions about
how to *disable* the Thunderbird apparmor profile. I think it currently
only explains how to re-enable the apparmor profile after it has been
disabled by the Thunderbird postinst script.

Cheers.

One way to restore the default Debian apparmor profile is perhaps somewhat of
overkill, but quite straightforward:

$ sudo apt purge thunderbird
$ sudo apt install thunderbird

Then reboot to ensure the changes take effect

I tested this, and after purging thunderbird, the Thunderbird apparmor profile file and
the symlink in the /etc/apparmor.d/disable directory are removed. Then if Thunderbird
is installed, the correct Debian version of /etc/apparmor.d/usr.bin.thunderbird
is restored and the symlink to disable the apparmor profile is also created. After a
reboot, Thunderbird launches successfully and now you would have a default
Thunderbird installation. The purge does not touch any profiles with Mail settings
for your accounts and messages stored in your home directory, and after the purge
and install steps and a reboot, Thunderbird continues to use the profiles of your
Mail accounts as expected. It is a very simple, quick, and easy process.

Cheers.

Hi Carsten,

Carsten Schoenert (2026-02-14):

Yup.

I've been trying since November 2024 to upstream Tails' updates, such
as this one, to the AppArmor profile:
https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/61

A few weeks ago, I've sent a last call for collaboration there.
No reply so far.

So, my next step, as announced on that MR a while ago, is to remove
the AppArmor profile from the Debian package in sid: without
a collaborative effort upstream, there's no good way for me to keep
maintaining it for Debian, with an amount of effort that I can
justify. Given the profile is so widely open and disabled by default,
that's not the end of the world. Not all experiments succeed, it's OK.

Thoughts?

If this works for you, I'll prepare a MR.

Thanks a lot for your patience so far,
cheers,

Hi intrigeri,

sorry for answering later but I'm busy with ongoing business trips.

Am 16.02.26 um 13:09 schrieb intrigeri:

Ohh, thats a long time and there are some more modifications needed or
useful for the profile I thought. But never did used AppArmor in Debian
in a serious way.

A problem what a lot of projects having and I do experiencing too while
working on some Python packages in Debian, projects are not fully dead
but did fade away due previous active members and decision makers have
given up or moved away from the project, or being just unresponsive.

It's hard to deal with this because it contradicts the principle of
pushing changes upstream first.

I'm totally fine with this decision!
Sometimes it's better to accept that a "fight" is lost before to loose
even more energy and time while trying to keep a fragile situation.

I've read about the indentation of you to let the chapter AppArmor end
in Debian a while ago. If this all is not fun enough while working on
this it's better to let it go, my interests what to work on have also
shifted in the past years. At the moment my time is limited to work good
enough on in time update for the TB package, so Christoph did stand up
to do this since a while.

You are welcome! Christoph an are happy to merge in your suggested
upstream modifications of the AppArmor profile into the current the
packaging of Thunderbird!

problems than it solves. I think the following bugs could be closed by
its removal:

https://bugs.debian.org/1128672
https://bugs.debian.org/1127710
https://bugs.debian.org/928178
https://bugs.debian.org/909281
https://bugs.debian.org/955380
https://bugs.debian.org/882218
https://bugs.debian.org/900210
https://bugs.debian.org/914403
https://bugs.debian.org/917613
https://bugs.debian.org/949450
https://bugs.debian.org/880424
https://bugs.debian.org/883245
https://bugs.debian.org/961269

and https://bugs.debian.org/949649 could either be closed or marked as
wontfix.

In particular, it has

   #include <abstractions/dbus-session>

which is a complete sandbox escape: lots of session services can be
asked to execute arbitrary code via D-Bus. It also has

   owner @{HOME}/.{cache,config}/dconf/user rw,

which is a complete sandbox escape via any dconf/GSettings option that
can be configured to run arbitrary commands, for example GNOME's
desktop-wide custom keyboard shortcuts.

Given those, I think this profile has no security value, so its
cost/benefit ratio is very low (it has the usability costs of a security
policy, but not the security benefit).

     smcv

Hi,

Carsten Schoenert (2026-02-22):

There you go: https://salsa.debian.org/mozilla-team/thunderbird/-/merge_requests/11

Cheers,

Hi Simon,

Simon McVittie (2026-02-22):
https://salsa.debian.org/mozilla-team/thunderbird/-/merge_requests/11

Thanks for this input!

Cheers,

We believe that the bug you reported is fixed in the latest version of
thunderbird, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1127710@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Carsten Schoenert <c.schoenert@t-online.de> (supplier of updated thunderbird package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 22 Jun 2026 21:41:06 +0200
Source: thunderbird
Architecture: source
Version: 1:152.0-1
Distribution: experimental
Urgency: medium
Maintainer: Carsten Schoenert <c.schoenert@t-online.de>
Changed-By: Carsten Schoenert <c.schoenert@t-online.de>
Closes: 880424 882218 883245 900210 909281 914403 917613 928178 949450 949649 955380 961269 1127710 1128672 1128876 1138513
Changes:
 thunderbird (1:152.0-1) experimental; urgency=medium
 .
   [ Carsten Schoenert ]
   * [5097e09] d/control: Bump B-D for libnss3-dev
   * [5350030] New upstream version 152.0
     (Closes: #1138513)
   * [92962df] Rebuild patch queue from patch-queue branch
     Removed patch (included upstream):
     fixes/Fix-conflicting-types-for-once_flag-and-call_once-with-gl.patch
     fixes/Fix-math_private.h-for-i386-FTBFS.patch
     fixes/Fix-sandbox-to-build-with-glibc-2.43.patch
   * [46de392] d/mozconfig.default: Remove option --enable-av1
 .
   [ Christoph Goehre ]
   * [5308430] rebuild patch queue from patch-queue branch (Closes: #1128876)
 .
   [ intrigeri ]
   * [77d16c3] Don't install AppArmor policy anymore
     (Closes: #1128672, #1127710, #928178, #909281, #955380, #882218, #900210,
      #914403, #917613, #949450, #880424, #883245, #961269, #949649)
Checksums-Sha1:
 1e9bca601d3dab684f2c1e34bbd107712eb17f8e 8402 thunderbird_152.0-1.dsc
 5ed145d0f72ee7e539f3f0d40cea83ed62b1499f 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 dbef2f6a94cec7b667931b222bdd6f0aaf9a4810 931861244 thunderbird_152.0.orig.tar.xz
 6fc9531bd0e3c27e7908228227a542966eb827f8 537512 thunderbird_152.0-1.debian.tar.xz
 41476b21bed4090bcf2c148b0178ef52d0e2f2e7 40158 thunderbird_152.0-1_amd64.buildinfo
Checksums-Sha256:
 8d348b506605fc73d56722d5a55ed9dae8af623989312e5c039786edfbe4f0f2 8402 thunderbird_152.0-1.dsc
 f4afa9846377239357e485da027035fe53762cc8100ced5cf5abca87fca7a1f8 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 64f02562f1f4a18e39c67b07255feb5828acde86327f55b1ebe45e3ac63963ea 931861244 thunderbird_152.0.orig.tar.xz
 52abff98afbeb3859791f46e5602bbbf6982f38876f7e223d0ff1ac7bb77c778 537512 thunderbird_152.0-1.debian.tar.xz
 38ab10bf14449c38f7233f8d883b1a6ffbe412606232763f9bcaa5dcda320c03 40158 thunderbird_152.0-1_amd64.buildinfo
Files:
 cddc168c5e8bdb4c051a11b4e56831b8 8402 mail optional thunderbird_152.0-1.dsc
 27c69983d0063061996fc52794377743 12403192 mail optional thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 f49e9b967f1a1fdceec316060aef4959 931861244 mail optional thunderbird_152.0.orig.tar.xz
 d435a5b441fa39456dfa21b01881fdf3 537512 mail optional thunderbird_152.0-1.debian.tar.xz
 20c10b422095bf9f1d461c01e152c30e 40158 mail optional thunderbird_152.0-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmo5mL4ACgkQgwFgFCUd
HbCPqw/+LEBi5TrBqIfSUOoosSHHufs3R4FzJrZ6vNsK4ur6EVNNhR1u0Gc4VtEG
JIaiGg7fCDf3mgAowEIKSQpVHnqMPKpqZemfIWHNT0exdKp1RXlh9OuwGdOqg0Og
5MWrhKzrDVr7p9LmB7ilQ2V0I+xHx1zh/cG58Ar2Pp9Wn8YDlpIQmO0vp6sX2ex5
GTUYHvVrssW4L/hOAsbMu9YUnGPRiHPvj94JF7XT2JFC6mndXtiqvEOH5Oo1UluK
FcM8Xz1GsANmwB4gR7/g0f06RWEjAsOMXPU98ESaY85kRTJ4VlVvGWOknGa0Sptv
frrEG893xRFXFmnrDR7dLH8Ux1cnsGy5wpNCZeLVViuT6Pv4OIm83jijKqaGHvp3
jdD8OWx7YGbYdm+INBBnff5Y/IEEni7EIuX17/S3ZNqlLYJGPbL6OWG+pMK52+xZ
0dMFXCrSMc+xMMUHBQ/aUw3up5t4B5de51tX9kWTFv3W/qIiLdA+PpH2EGiJJJIF
Jgm9q0sAlXLC2GZW55MTbk2/jhewQOcShIRrEKFJUPzpPgeXZAAN/I47uKAzoUAW
0x/Hb0+b72NKBlK8jurZfKYBDPyxLnHSUcCbVCPj8SyzxcCHBZ12jsVhIEjUwMEH
cyFP/Ep5MDC7yo9XX+Xt4na47jktwLRJ5jRpySaIV9RfhvBHPNQ=
=jjF1
-----END PGP SIGNATURE-----