Hi, Am 02.05.19 um 09:05 schrieb Ulrike Uhlig: >> Well, but who has enabled AA in PC? I'm sure that I have not worked on >> /etc in these days and I am the only one can access on it. In my opinion >> there is a bug in some package update that has enabled TB AA profile... >> but in effect I realize that to be believable someone else would find >> this unbelievable behaviour... > > Maybe you accidentally upgraded to Buster or you are using a kernel that > has AA enabled by default.
the starting email of this bugreport is showing an installed kernel from backports. So for me it's quite obvious *why* apparmor is installed and has activated all the profiles for the various packages that come along with AA profiles which should be also activated then. > Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/4 CPU cores) > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), > LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) I can remember we have such discussions again and again from time to time and users are surprised why Thunderbird isn't working any more as usual or expected after some random update. So far I remember it was always an active TB AA profile. And users are even more surprised if I tell them the TB packaging in Stretch did never had an automatically activated AA profile, in other words, they have it activated it by themselves. In this report there are two things that have come together in my eyes. 1.) An activated AA profile for Thunderbird. 2.) An different path for ${HOME} because of an membership within a Windows domain. The first one isn't a big problem anymore in newer days, the current AA profile is covering for sure about 95% of the use cases. The second point isn't covered nicely until now in the AppArmor installations within Debian at least. But I think also that Thunderbird isn't the only package that will suffer from this problem and we will need a more general solution for this. And this needs to go into Apparmor itself instead of every body tries to implement some super logic within their AA package profile. Currently I've no idea how to detect a membership of a Windows domain nicely, for sure this is solvable by some PAM voodoo. I have simply no knowledge in this area. And I have no environment to test something. It seems we just need to trigger a dpkg-reconfigure of AA if the PC is within a domain membership. -- Regards Carsten Schoenert