aa-log output and git broken

[openresolver]

Hey git is broken for me right now - admittedly I probably jumped the gun and installed the enforced profiles too soon but I was excited to see what broke!

When trying to run sudo aa-complain git I get:
sudo aa-complain git
ERROR: Syntax Error: Unknown line found in file /etc/apparmor.d/abstractions/gtk-strict line 18:
priority=-1 @{bin}/bwrap px -> glycin,
zsh: exit 1 sudo aa-complain git

I also get the same when running sudo aa-complain /etc/apparmor.d/swapon
"sudo aa-complain /etc/apparmor.d/swapon
ERROR: Syntax Error: Unknow

aa-log.txt

n line found in file /etc/apparmor.d/abstractions/gtk-strict line 18:
priority=-1 @{bin}/bwrap px -> glycin,
zsh: exit 1 sudo aa-complain /etc/apparmor.d/swapon

I did try to mess with the syntax error but it just made for more of a mess. Every line that got changed created another problem as it always does with apparmor.

Do you want me to post the remaining logs here in the open issue? There are a fair amount of them. I can paste them into a file with some better formatting if you'd rather have that. FWIW - I can boot and use my computer normally (besides git and my encrypted swapfile service at boot) with the enforced profiles installed.

[openresolver]

The "aa-log.txt" in the OP is the log file

[roddhjav]

Thanks for the logs, I have fixed most of the issues. However, there is no mention of git in these logs.

Can you ensure you set your project dir: https://apparmor.pujol.io/configuration/#program-personalization

Regarding the issue with aa-complain/aa-enforce, it is a well known bug in the tooling. There is nothing I can do.

[openresolver]

No worries! I RTFM and found out that part of the issue I was having was indeed variables and that if they are not set yet, they need to be set first with an "=" and then after you can add more with "+=", is that correct? I think I finally got all my variables set properly because I followed that syntax and now I'm having no issues restarting apparmor for issues related to variable declaration - still having issues related to the priority=-1 @{bin}/bwrap px -> glycin, but I understand that seems to be expected right now.

Here's the interesting part (or maybe not, I'm still fairly new to apparmor so its a learning curve)... I made sure my build and project dirs were set. BEFORE I had them set properly, I got these logs and git wouldn't work:

DENIED git open owner @{HOME}/hardened-kernel/linux-6.17.13/.git/HEAD comm=git requested_mask=r denied_mask=r

After setting them, I don't seem to log any errors for git but I still can't run git status

Also having an issue with libvirtd - virt manager isn't connecting due to:

DENIED libvirtd ptrace comm=rpc-libvirtd requested_mask=read denied_mask=read peer=virt-manager

I am including a 2nd log file too with some different logs for apt. Thank you for your reply and your work on the project.

aa-log2.txt

[roddhjav]

I think your second log file is broken.

[openresolver]

aa-log2.txt

Sorry about that - trying again

Edit (sorry for the 6 edits lol the markdown is killing me):

I tracked this down and wanted to report back with the root cause and fix.

I did explicitly configure my tunables so that my kernel tree is treated as a project. In particular, I set the relevant values under:

/etc/apparmor.d/tunables/xdg-user-dirs.d/apparmor.d.d/local

However, when debugging, I noticed that @{user_projects_dirs} was still expanding to:

@{HOME}/@{XDG_PROJECTS_DIR}

which on my system resolves to

~/Projects", not my kernel tree (~/hardened-kernel/**)

. Running grep against the loaded tunables consistently showed @{user_projects_dirs} pointing at the XDG projects directory, despite my local overrides (even tried to override /Projects).

At the same time, @{user_build_dirs} was correctly picking up my kernel tree (I have @{user_build_dirs}+="/home/user/hardened-kernel/**"), and rules scoped to build dirs matched as expected.

Because of that, Git repository metadata access (.git/HEAD, etc.) was being denied when restricted to @{user_projects_dirs}, but worked immediately once the profile was switched to use:

@{user_build_dirs}/**/.git/**

So the practical fix on my system was to tie Git’s .git metadata access to @{user_build_dirs} rather than @{user_projects_dirs}. This avoids reliance on XDG user-dirs expansion, which appears to override or bypass local tunable expectations in this case.