I don't believe this is the right fix. My read of the apparmor issue is we need to add a "unix" term, not a "network unix" term.

I don't believe this is the right fix. My read of the apparmor issue is we need to add a "unix" term, not a "network unix" term.

you are right, I checked the manual page https://manpages.ubuntu.com/manpages/noble/man5/apparmor.d.5.html,
Thanks @achernya

I can't find apparmor doc about change the behavior about network @achernya

@ningmingxiao I wrote more details in #12726 -- specifically take a look at https://gitlab.com/apparmor/apparmor/-/issues/561 where John Johansen says "[...], in that under newer abi's unix rules are not covered by the generic network socket rule, you have to create a unix rule.".

Later on John also says "What apparmor does for abis, is take an intersection of what the policy was authored under, and what the kernel supports, to find a common set of features." -- since containerd is not declaring an ABI, we are auto-migrated to the newer ABI as the kernel supports it, which eventually removes network unix from network.

since containerd is not declaring an ABI, we are auto-migrated to the newer ABI as the kernel supports it

It sounds like it would be best for us to declare an ABI here as well then?

That is the fix I had in mind when I reported #12726; my biggest issue (as a user but not contributor) was figuring out how to add a test for this.

my biggest issue (as a user but not contributor) was figuring out how to add a test for this.

Our guidelines for the contrib folder (and specifically the apparmor and selinux profiles) are a bit looser since they're often very platform-dependent; if we're able to test this manually on both recent systems and still-supported older ones I think that's reasonable.

@nmn3m Do you plan to update this to address the comments?

@nmn3m Do you plan to update this to address the comments?

Yes, I've updated the PR to address the feedback:

1. Changed from network unix, to unix, (already done in previous commit)
2. Added ABI declaration support - the template now detects if abi/4.0 or abi/3.0 exists on the system and includes the appropriate abi <abi/X.0>, declaration in the profile
   preamble

This ensures consistent behavior across different kernel versions by explicitly declaring the ABI rather than relying on auto-migration.

@nmn3m I don't think this strategy makes sense as currently implemented in the PR.

1. Neither abi/4.0 nor abi/3.0 want the unix term, they're ones that support network unix, so if we're going with ABI, then we should revert the unix term change.
2. Detecting if the system has a particular ABI isn't semantically correct. The ABI of the apparmor configuration is a property of the configuration written. That means that if the intended ABI is 4.0, we should always use 4.0; likewise if it's 3.0. Looking at https://gitlab.com/apparmor/apparmor, it looks like ABI 3.0 was added in 2020 and ABI 4.0 was added in 2023, corresponding to the apparmor versions of the same release line. It's not obvious to me what kernel versions/apparmor versions containerd's support policy wants to support by reading https://github.com/containerd/containerd/blob/main/RELEASES.md; however the 1.7 line is LTS and came out March 2023, which is a bit before the 4.0 ABI. Doing some more research, it looks like between 4baa187 and c990e3f the policy is really intended for versions of apparmor >= 2.8.96, which strongly points to the 3.0 ABI being the correct choice.

@nmn3m I don't think this strategy makes sense as currently implemented in the PR.

1. Neither abi/4.0 nor abi/3.0 want the `unix` term, they're ones that support `network unix`, so if we're going with ABI, then we should revert the `unix` term change.

2. Detecting if the system has a particular ABI isn't semantically correct. The ABI of the apparmor configuration is a property of the configuration written. That means that if the intended ABI is 4.0, we should always use 4.0; likewise if it's 3.0. Looking at https://gitlab.com/apparmor/apparmor, it looks like [ABI 3.0 was added in 2020](https://gitlab.com/apparmor/apparmor/-/commit/730db1760704790595f0d8b01552e10aba16ef4c) and [ABI 4.0 was added in 2023](https://gitlab.com/apparmor/apparmor/-/commit/f1b4da2f64459c1715b8c2157e33ebd2e26ab253), corresponding to the apparmor versions of the same release line. It's not obvious to me what kernel versions/apparmor versions containerd's support policy wants to support by reading https://github.com/containerd/containerd/blob/main/RELEASES.md; however the 1.7 line is LTS and came out March 2023, which is a bit before the 4.0 ABI. Doing some more research, it looks like between [4baa187](https://github.com/containerd/containerd/commit/4baa1876ba45ffdab9059753215aa1c5d6f79b1d) and [c990e3f](https://github.com/containerd/containerd/commit/c990e3f2ed88637ac084d32c08f658b211298b61) the policy is really intended for versions of apparmor >= 2.8.96, which strongly points to the 3.0 ABI being the correct choice.

Thanks for the detailed feedback. I may be missing some context, but I’m not fully confident I understand the exact requirements or the intended ABI strategy here.

Given the ABI semantics and compatibility concerns you outlined, I’m not sure I’m the best person to continue driving this change.

I've written up an alternative pull request #12864 and performed one-off testing that looks successful.

Closing in favor of #12864. Thanks @nmn3m for the initial contribution and @achernya for following up!