We will ship apparmor 5 in snapd snap when we have confidence that there are no regressions. We are working on this together with the apparmor team.
2 Likes
ah just saw apparmor 4.1.6 got release, but i now understand it is waiting on apparmor 5ā got it appreciate yāall are ironing things out as much as possible <3
Just in answer to this. The snapd snap needs to be somewhat cautious about shipping apparmor versions. There are two main reasons for this. Firstly, since the same snapd snap is released across many versions of Ubuntu in support, so we need to ensure there arenāt regressions caused by version combinations between the kernel, the host distro, and snaps. Secondly, our install base includes very low-end IoT devices on Core, so we have to be careful about performance.
Our plan was somewhat delayed by some issues fixed in 4.1.3/4. Weāre now pushing to vendor 4.1.x into snapd 2.75, and v5 into snapd 2.76.
2 Likes
This is great news! I also saw apparmor 5 is at alpha-6 (although resolute still claims alpha-1; maybe its only the package name?).
Thank you so much for that update!
JFYI apparmor released its first beta for apparmor 5 (after 6 alpha releases; https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_5.0.0-beta1). It has a caveat to distros using 5.0 vs 5.1
I am not sure if it is also directed towards Ubuntu OS usage and usage in the snap or not. Canonical people probably know.
Apparmor 4 seems to shake out bugs, 4.1.5 fixes python compatibility and regressions still related to getting unprivileged user namespaces right (4.1.6 fixes an regression introduced by 4.1.5).
Could someone explain what this and above requests mean in practice? Could these changes allow other than Ubuntu Linux distribution finally use snapd and snap packages on same confinement and security / OOTB convenience levels as in Ubuntu? Something else entirely?
I am actively working on integrating both 4.x and 5.x into snapd. This is complex as apparmor 4.x has had some regression (now mostly fixed) and apparmor 5 is neither ready upstream nor downstream in snapd.
In the end we should have good sandboxing on any system using upstream kernels but this is likely a 26.10 goal.
So simply put, this will mean that distros that recently dropped the snapd and sna snap packaging entirely recently (Solus, KDE Linux and so on) because of messy structure, permissions, AppArmor problems and so on, can reconsider snapd in future?
It is unbelievable to me that even though Snapcraft page has comprehensive instructions on how to add snapd to use snap packages on a chose distro other than Ubuntu, the experience is sub par and filled with warning, error messages and so on to this date.
Shipping snapd is not very difficult. We are working on making it more consistent across distributions by improving snapd.mk and calligraphy that from packaging scripts.
As for confinement this has been a long running quest to improve the state of apparmor in the upstream kernel and in distributions using it.
Now about removal or re-intrroduction it is hard for me to say. I donāt have the bandwidth to keep a close eye on all of the distributions (big and small).
We spent some time on the ability to reuse the language of appamror profiles on non-apparmor systems (e.g. selinux) but this effort is long and slow.
The bottom one is that anyone can ship or not ship snapd whenever they want. At most we can improve the code to make technical decisions easier.
1 Like
Speaking of KDE Linux, Iām sad that they dropped Snap mainly because itās in AUR and not in the official repos. Any ideas if itāll ever get there?
It seems it would need a Arch repo packager to invest the time into maintenance.
the only criterion for introducing new (redistributable) packages in the Arch repos is having a packager willing to maintain it. And I highly doubt any of them would find a third party distro needing a package a compelling reason to invest their time in maintaining it, particularly for packages which are not useful in Arch (calamares, steam-devices-git) or are frowned upon (snapd).
https://invent.kde.org/kde-linux/kde-linux-packages/-/merge_requests/69
Packaging snapd as a flatpak might work instead?
FWIW, I maintain snapd in AUR, but Iām not sure Iād be willing to invest time and energy in getting it into extra. Iāve been using Arch long enough (since 2003/2004) to have my own reasons for not getting involved or trying to become a maintainer even for the extra repository.
Just an update to those subscribed. The information we got was that apparmor 5 will be included in snap 2.76 which is supposed to arrive May 18th in beta.
What is certain is that AppArmor 5.0 got released and Zyga has some snapd branches using apparmor 5. It did not arrive in the official snapd repository though.
There is cleanup/polishing work going on on AppArmor 5 (e.g. reenabling features, updated profiles) and AppArmor 4.1 (which gets vendored in snapd currently). To me it seems that AppArmor 5 might be stable enough to rely on it in snapd
There is no commitment to content for snapd 2.76 in the roadmap (content will be shared closer to release), so just lets hope for the best. The followup snapd milestones (>=2.77) seem to be syncing milestones with the ubuntu 26.10 release.
thereās been a lot of discussion about vendoring the user space AppArmor utilities into the snapd snap, but this topic was originally about the requirement for kernel-side patches that arenāt in the upstream kernel.org source tree. I still donāt think any of the mentions of vendoring have even come close to actually resolving that, and the only, question posed at the top of the thread.
edit to fix autocorrect errors (Iām on my Mac right now)
Hi OP, I guess you have been out of the loop for a while? Or I misunderstood. As far as I know all necessary kernel changes have been upstreamed (its somewhere in the thread) a while ago. But for non-ubuntu distributions, the user space and policies need to be adapted to the upstreamed changes (using a new ABI). We got the information from the snapd team that would be the case with AppArmor 5.
So regarding the original topic, my understanding it this is solved, but it does not help anybody (yet).
1 Like