On 2/14/2026 4:23 PM, Carsten Schoenert wrote: > Control: tags -1 severity important > Control: usertags -1 tb-apparmor > > Hi, > > Am 14.02.26 um 22:51 schrieb Jeremy Bícha: > > On Sat, Feb 14, 2026 at 3:42 PM Debian Tester <[email protected]> wrote: > >> 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. > > 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.
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.
