Dear Maintainer,

I store my profiles under $HOME/Archives/.thunderbird with a symlink to
$HOME/.thunderbird to allow easier backup. I recently have had an apparmor
error, with a denial to lock the .parentlock file. This results in
thunderbird/icedove unable to start since no profile can ever be locked.

Creation of the .parentlock file is ok, but I suppose this is because write
permissions are give on the subdirectory from $Home. I don't know why I did not
have that before, since the apparmor profile is not really new.

Switching to the upstream version locally installed in /opt results in correct
operation.

A good way to reproduce would be either create a new profile outise of
~/.thunderbird or to move the entire ~/.thunderbird directory to another
directory (e.g., /tmp/thunderbird) and symlink it back to ~/.thunderbird.

All the best,
David.

I'm also affected by this bug.  At the moment my home directory is on
an NFS share, and my quota isn't big enough to fit my mailboxes (in
addition to making the NFS server a bottleneck for mailbox
operations).

Not sure how the AppArmor stuff works -- would it be possible to
restrict the profile directory *after* reading profile.ini, so you
know where the actual profile lives?

Thanks,
 -George

Unfortunately, the current profile only supports files inside
~/.{thunderbird,icedove} and Apparmor doesn't consider symlinks. It only
considers the final destination when matching against the profile.

That would certainly be a good idea but would require upstream efforts
to support Apparmor properly.

I'm afraid that for such cases, the easiest solution would be to disable
the Apparmor profile:

  sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird
  sudo ln -s /etc/apparmor.d/usr.bin.thunderbird
/etc/apparmor.d/disable/thunderbird

Regards,
Simon

Hi,

Simon Deziel:

Right. libvirt-daemon does exactly that, but note that loading
AppArmor policy into the kernel requires root.

… or use bind-mounts instead of symlinks, so that your profiles
are exposed in ~/.thunderbird to AppArmor.

Or add local configuration such as:

    echo "  owner /path/to/your/profile/ rw," \
       | sudo tee -a /etc/apparmor.d/local/usr.bin.thunderbird
    echo "  owner /path/to/your/profile/** rwk," \
       | sudo tee -a /etc/apparmor.d/local/usr.bin.thunderbird
    sudo apparmor_parser -r /etc/apparmor.d/usr.bin.thunderbird

Once again, we should document this limitation (+ workaround) in
README.Debian.

And then we need to decide whether it's good enough or we should ship
this profile disabled by default.

Cheers,

That's clever!

I've been thinking some more and I think that having it disabled by
default is the way to go.

Regards,
Simon

Right, I was thinking of hat changing or switching to a child profile
but that's wrong because it would be an entirely new profile tailored to
the profile.ini. Thanks for the clarification.

Dear Maintainer,

I am suggesting to fix this issue by providing @{thunderbird_user_dirs} variable, that could be modified by the user to
add addition paths, such `/home/me/Archives` or `/mnt/foo`. This kind of functionality is discussed in AppArmor mailing
list [0].

I have tested with `/etc/apparmor.d/local/tunables/usr.bin.thunderbird` having this content:

```
@{thunderbird_user_dirs} += /mnt/foo /home/vincas/Archive/
```

And it solves this issue, provided that profile has patch applied of course.

_The question is_, will you agree to ship empty file `/etc/apparmor.d/local/tunables/usr.bin.thunderbird`? We do not
have "#include_if_exists" or similar mechanism in AppArmor parser to avoid that yet.

Additionally, maybe Thunderbird's README could have useful information about this customization point.

I have attached WIP patch that I will propose to AppArmor pull request myself, but only if you agree with this plan.

[0] https://lists.ubuntu.com/archives/apparmor/2017-December/011350.html

Hello Vincas,

I'm not against to ship such a empty file.
OTHOH I have not deep knowledge how AppArmor is working internaly, but
in the longterm we would need some mechanism that allows users to config
the needed behaviour inside their Home.

Couldn't be something added like this?

  #include_if_exists <@HOME/.config/apparmor/usr.bin.*>

As long as apparmor stuff is placed in /etc/apparmor the user needs
admin rights to chnage or add something. That's mostly no problem if the
user is a typical SOHO user but quite impossible if using a Linux system
on a university or company e.g.

If the above is possible we could prepare some example stuff in
/u/s/d/thunderbird that user can simply copy and change to their needs.

That's of course needed. I was thinking about a new additional file
README.apparmor for that extra information. This file will grow over
time I think.

We can add that change of course as we need to start somethere. For
52.5.0 it's to late now. But I can upload a further version with more
apparmor related changes in the next weeks.

Regards
Carsten

John was talking about "policy namespaces" on #apparmor:

```
[2017 m. november 29 d., wednesday] [21:32:18 EET] <jjohansen> Or a user could have a firefox profile, and could edit it
and load it without being a sysadmin
[2017 m. november 29 d., wednesday] [21:33:20 EET] <jjohansen> the sysadmin could specify a separate firefox profile if
so desired or they may decide to just have a role type profile on the user and let the user worry about differentiating
their own applications
[2017 m. november 29 d., wednesday] [21:33:30 EET] <jjohansen> it opens up a lot of possibilities
```

Not sure when this feature will come up though.

If we had only that `#include_if_exists` (and we don't), this example would include rules from all users (that has it
defined) in the system into one global policy applied to all users, so not sure if that's OK. Also, reloading policy
after applied changes would still need root permissions too. So, we need that policy-per-user, a.k.a "policy namespaces"
as JJ talked about, _if_ I understood that correctly.

Well, if we are bound to wait for "policy namespaces", my patch probably (not sure how variable would be handled in that
way) becomes redundant. If we wait for #include_if_exists, empty file is unneeded.

Most realistic approach (IMHO) would still be with an empty file and a new @{thunderbird_user_dirs} variable as in the
patch, so that affected users of this bug report could extend Thunderbird policy without modifying main profile (which
would get overwritten after update), and with writing only one line into
/etc/apparmor.d/local/tunables/usr.local.bin.thunderbird. Only because timeline is within the weeks, not.. well, I do
not know how long :-) .

Hi,

Am 04.12.2017 um 18:46 schrieb Vincas Dargis:

that's probably what I meant to describe.
I would appreciate if any user could add additional rules on top of the
existing profile without extra needed sudo rights. But only with the
possibility to free up restriction inside the users home.

...

Yes, that would solve such issues like this report here.
Some days I've written to intrigeri that AppArmor would need in the long
term some GUI stuff where users can easily inspect the current enabled
profiles, see logging stuff (and if put the above all together) tune up
things within their own access level.
But this all would need some extra new features inside apparmor I guess.

If we add the now possible @{thunderbird_user_dirs} directive we need to
think about some migration scenario too. The impact on the user side and
the need to modify their rules set up for a second time must be small as
possible. And a decision based an a broader view need to take care also
about other application profiles that may need some extra rules on some
of the users side too.

Currently I haven't enough time to think about all that various things
nor will I have in the next months unfortunately.
But if you all came up with a solution that will cover most of the
things I happily will trust on intrigeri to collect the right things and
push them into the thunderbird packaging.

Yeah, I miss some sort of convenient auditing tool too.

I do not see the need for migration of any kind. @{thunderbird_user_dirs} will be set to @{HOME}, so _by default profile
will work the same as before_.

OP of this bug report will be able to extend this variable in `/etc/apparmor.d/local/tunables/usr.bin.thunderbird` file
by adding single line `@{thunderbird_user_dirs} += @{HOME}/Archives/`, and reloading profile. This customization point
could be documented in README.Apparmor as suggested.

As for other applications, these `local/tunables` variable files could be used for media players (or other
document-opening-applications) too, for example, to allow extending "extra_read_dirs" as /mnt, /media, /srv etc. to more
places as needed, without writing full rules in `local` file.

Libreoffice profile already uses a lot of variables, but there is no kind `local/tunables` include file used, so user
must edit main profile in order to extend, which is not OK (battle against package manager).

Discussion about using AppArmor variables more as in this use case is still ongoing, and looks like there is agreement
in general from intrigeri and John Johansen, though some details needs to be resolve yet.

Hi,

Vincas Dargis:

What's the status here?

The "pending" tag seems to be misleading: either we consider that we
solved this with #882218 (and then let's close this bug) or we don't
(and then let's drop the "pending" tag).

Cheers,

Control: tags -1 -pending

Yes, I believe there should not be "pending" tag set.

I have this on TODO, but I need to have this bug fixed first (issue with
variables in local/something and other seemingly non-standard directories):
https://bugs.launchpad.net/apparmor/+bug/1331856

Also, conditional includes would make packaging easy, meaning there
would be no need to package local/tunables/usr.bin.thunderbird.d nor
tunables/usr.bin.thunderbird.d (where distribution-specific variables
_could_ be placed, if needed). But that's gonna be with AppArmor 3.0 I
presume?

Justification: to hit this bug, one has to apply two changes to the
default configuration (opt-in for AppArmor confinement and store
profiles in a non-default location).

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 882218@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-----