aa-logprof partially broken even when installing specific profiles about apparmor.d HOT 8 CLOSED

I'm very happy to report that aa-logprof seems to work again with the newest AppArmor version 3.1.2 on Arch Linux! I'm not sure which commit fixed this issue.

I'll leave this issue open for another couple of days until I'm sure that everything is okay.

EDIT: Note that I haven't tested the new version with regard to the @{exec_path} problem yet.

from apparmor.d.

I don't think that this issue can be traced back to https://gitlab.com/apparmor/apparmor/-/issues/90 as I remove all instances of @{exec_path} . The problem must be caused by something else, IMO.

from apparmor.d.

The problem is indirectly due to @{exec_path}. In practice the source cause is that the python library behind aa-logprof does not parse variable used in profile attachment (and possibly too in profile header). This is a know bug in AppArmor. But has it is not trivial to fix, it has be open for years.

from apparmor.d.

I'm not quite sure that I understand. Do you mean the additional variables introduced by this project?

If so - does that mean that it would be necessary to rewrite every profile by removing those additional variables?

from apparmor.d.

No, I mean the variables defined in a profile preamble (just before the profile ... line) not the one in the tunables

To sum up, this issue might still be open for years as it is not easy to fix.

from apparmor.d.

No, I mean the variables defined in a profile preamble (just before the profile ... line) not the one in the tunables

Ah, I see - but, quite frankly, I'm not fully convinced. I had been using the libreoffice profiles (which originally come from Canonical) for some years. The *.soffice.bin profile contains variables ( @{libreoffice_ext} and @{libo_user_dirs} ) as well and they had never caused any trouble with aa-logprof. Similarly, I've been using @{okular_ext} = [eE][pP][uU][bB] [pP][dD][fF]
in my okular profile for some time without any problems.

So I still think that there must be another culprit.

from apparmor.d.

EDIT: Note that I haven't tested the new version with regard to the @{exec_path} problem yet.

Unfortunately, this problem still exists.

from apparmor.d.

Closing as fixed by upstream.

from apparmor.d.