On 04/01/2018 08:04 PM, Goldwyn Rodrigues wrote: > Hi, > > This is in reference to the socket mediation patch (commit id > 56974a6fcfef69ee0825bd66ed13e92070ac5224) in apparmor-next branch. > Why should there be an ABI change for this? Why should the SFS directory > be called network_v8 as opposed to just network? Is it because of > network directories earlier/distro kernels? How does it affect userspace > utils? > >
Hey Goldwyn, this has been discussed a few times in the IRC channel and other places but I guess it has never been discussed in sufficient detail on the ml. Linus reverted the networking patch in 4.14. The only way to come close to meeting the requirements laid out then was to change the ABI of the networking patch so that old userspaces will not generate networking rules and cause breakage for kernel developers. The new abi on the patch however is not sufficient as just introducing the new abi to the parser will lead to the same problem that lead to the revert. To fix this userspace must transition to policy versioning, which has seen some discussion on the list. What this means for the userspace tools is they will continue to work with the old networking abi, but older versions of the tools will never work with the new abi. Support for the new abi will be introduced in apparmor 3.0 with policy versioning, and there will never be an upstream patch to allow the apparmor 2.x userspace to support the new abi; as the risk to the projects ability to land new features upstream is too great. If you are a distro that has carried the old networking patch there shouldn't be any need to drop it at this time as that will lead to a regression in the distro. Instead upstream kernels going forward will be limited to the pre-networking abi on releases with an apparmor 2.x userspace. A kernel patch adding support for the old networking abi to newer kernels is possible, and would allow distros to support both old and new networking abis during a transition period, at the cost of continuing to carry a patch that will not go upstream (Eg ubunut might want to use it for their HWE kernels where a new kernel is brought back to an older release). Going forward policy development will change some what. If not using policy pinning (almost everyone doesn't) policy will not automatically get policy recompiled for new kernel abis which can result in denials and failures that lead to the 4.14 revert. Instead policy will be compiled using its embedded policy version, and loaded to the kernel using that. If an author wants to update policy to use new features, they will need to update the policy to declare that policy as using the particular abi and then the policy can be built and loaded into the kernel. This may seem inconvenient, it can be for policy authors during a development cycle where you may want bug reports and to be updating policy to a new abi. But it will lead to a better experience for users, application developers who are shipping policy as part of their package, and distros who want to hold policy to a supported abi over the life of the release. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
