Upgrading from 2.59.5 to 2.60.x breaks all snap apps from launching:
$ code
cannot create user data directory: /home/COMPANY/myownuser/snap/code/137: Permission denied
We’ve been able to replicate this on 30+ machines, on both Ubuntu 22 and 20.
The issue is also very reproducable:
snap revert snapd # downgrades back to 19457
snap refresh snapd # upgrades to 19993 again
spotify # broken
The issue can be fixed by copying the apparmor config 19993 to the apparmor.d location, but this is not a permanent fix, as any time afterwards any snap is refreshed the user has to run “systemctl restart apparmor” (without needing to copy the file again).
$ code # BROKEN
cannot create user data directory: /home/COMPANY/myownuser/snap/code/137: Permission denied
$ sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real
$ code # WORKS
But this is suddenly starting to happen on a large amount of machines, and it would be inconvenient if this command has to be run every time snapd has refreshed.
@milachew Are you using a local account? Can you try move your home folder to /home/COMPANY/ubuntu, update /etc/passwd, and add the home.d path for apparmor?
You don’t need a fully AD-joined machine to replicate, you just need to move it to a sub folder in /home.
Seems the latest snapd ships its own apparmor implementation to be more independent from the host packages and it smells like that implementation does not source the home.d overrides… as a quick interim workaround you can simply roll back snapd via:
For anyone affected by this could you please try running the following:
echo 'include if exists "/etc/apparmor.d/tunables/home.d"' | sudo tee -a /var/lib/snapd/apparmor/snap-tuning
sudo systemctl restart snapd.apparmor.service # or just reboot
and let me know if that helps for now?
Actually I see now this issue is in the apparmor profile for snap-confine, which unfortunately does not include the snap-tuning file - so the above suggestion will likely not work. This will need to be fixed in snapd itself I think.
Sadly the bug escaped testing because while we have an integration test for the feature this test was not using the vendored apparmor feature from the snapd and only this combination triggers the bug. This is of course fixed as well and as part of the fix both variants are integration tested now.
AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap-confine.snapd.20092 in /var/lib/snapd/apparmor/profiles/snap-confine.snapd.20092 at line 3: Could not open ‘if’
Thanks for this error report, do you see this when you run apparmor_parser manually or is this something that snapd will have somewhere in it’s error logs? The former is expected, the apparmor_parser on 18.04 is older than the apparmor_parser that the snapd snap ships so only the version in /snap/snapd/current/usr/lib/snapd/appamor_parser will support all the new syntax.