Comment 30 for bug 2046844

So the answer is it depends on how they are using unprivileged user namespaces and how they react to them being denied, not every application needs to patched separately.

Generally speaking gnome has been better tested than KDE had because gnome being the Ubuntu default saw a lot more opt in testing in Lunar and Mantic. There is also some differences in how gnome and KDE handle their respective use of their respective browser components that has made KDE current require more direct patching.

We do have some improvements coming down the pipes that will make it easier to have a few some more generic profiles to cover different use patterns. Eg. not all uses of user namespaces set up mappings for the user, some will fallback to a degrade sandbox if an unprivileged user namespace isn't available while others will refuse to function.

Scarlett us doing excellent work within the current limitations. That work will continue to function once the improvements have landed, but it is likely you will see refinements on the current work once those improvements are available.

In general developers are going to have to become aware that user namespaces are going to be more restricted going forward, as its not just Canonical/apparmor pushing on this but SELinux, and likely other LSMs as well in the future. Eg. I have seen BPF LSM using this, and I expect to see some work on the smack side, because the original LSM hook proposals for user namespace mediation came out some work they did.

As for Gnome devs being aware of this bug, yes some are but it has not atm been a major issue for them. Long term I expect both KDE and gnome to take this is a policy issue for the respective LSMs, except when it surfaces code bugs, like some of their library code failing to check if clone/unshare failed, leading to a crash.

Fixing policy to deal with how applications, gnome and KDE use user namespaces will be largely an upstream LSM, or distro problem.