apparmor fails after removal of snapd

Hello Dale.

It seems, that I've had the same/similar problem with AppArmor and 'usr.lib.snapd.snap-confine.real' profile [1]. The strange thing was, that I couldn't change the enforcement mode for any profile! For example Firefox etc.

Please edit this profile and check if this line is commented. If it isn't then You can do this by adding '#' etc.:

- include "/var/lib/snapd/apparmor/snap-confine"
+ #include "/var/lib/snapd/apparmor/snap-confine"

Next, reboot system or reload AppArmor service. In my case, commenting an include '/var/lib/snapd/apparmor/snap-confine.d' line, fixed this issue, which seems to be similar to your problem. However, it should be fixed via 'snapd' package update but I don't remember if there was such an update. Anyway, I hope it will help You.

Thanks, best regards.
_____________________
[1] https://lists.ubuntu.com/archives/apparmor/2017-November/011330.html

Note that #include is NOT a comment. That's a valid way to perform the include function.

How did you uninstall snapd?

It's probably a bug in the snapd maintainer scripts to leave
/etc/apparmor.d/anything
around if that file includes another file that is removed with apt-get remove.

Thanks

The maintainer scripts definitely remove that file but perhaps something went wrong and the installation was only partial. Do you have any dpkg logs from the removal?

I do 99% of my package management with apt-get so it was removed via the command "sudo apt-get remove snapd"

From dkpg.log from just either side of the last mentions of snapd
2018-05-16 13:29:33 startup packages remove
2018-05-16 13:29:33 status installed snapd:amd64 2.32.8+18.04
2018-05-16 13:29:33 remove snapd:amd64 2.32.8+18.04 <none>
2018-05-16 13:29:33 status half-configured snapd:amd64 2.32.8+18.04
2018-05-16 13:29:33 status half-installed snapd:amd64 2.32.8+18.04
2018-05-16 13:29:33 status triggers-pending man-db:amd64 2.8.3-2
2018-05-16 13:29:36 status config-files snapd:amd64 2.32.8+18.04
2018-05-16 13:29:36 status config-files snapd:amd64 2.32.8+18.04
2018-05-16 13:29:36 startup packages configure
2018-05-16 13:29:36 trigproc man-db:amd64 2.8.3-2 <none>
2018-05-16 13:29:36 status half-configured man-db:amd64 2.8.3-2
2018-05-16 13:29:37 status installed man-db:amd64 2.8.3-2

apt/history.log gives this date (which time seems to coincide with the finish of the process, not the issue of the command, comparing to the above.)
Start-Date: 2018-05-16 13:29:33
Commandline: apt-get remove snapd
Requested-By: me (1000)
Remove: snapd:amd64 (2.32.8+18.04)
End-Date: 2018-05-16 13:29:37

apt/term.log from the system upgrade and then remove snapd.
Log started: 2018-05-16 13:29:07
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 352517 files and directories currently installed.)
Preparing to unpack .../libpoppler-qt5-1_0.62.0-2ubuntu2.1_amd64.deb ...
Unpacking libpoppler-qt5-1:amd64 (0.62.0-2ubuntu2.1) over (0.62.0-2ubuntu2) ...
Preparing to unpack .../poppler-utils_0.62.0-2ubuntu2.1_amd64.deb ...
Unpacking poppler-utils (0.62.0-2ubuntu2.1) over (0.62.0-2ubuntu2) ...
Preparing to unpack .../libpoppler-glib8_0.62.0-2ubuntu2.1_amd64.deb ...
Unpacking libpoppler-glib8:amd64 (0.62.0-2ubuntu2.1) over (0.62.0-2ubuntu2) ...
Preparing to unpack .../libpoppler73_0.62.0-2ubuntu2.1_amd64.deb ...
Unpacking libpoppler73:amd64 (0.62.0-2ubuntu2.1) over (0.62.0-2ubuntu2) ...
Preparing to unpack .../snapd_2.32.8+18.04_amd64.deb ...
Unpacking snapd (2.32.8+18.04) over (2.32.5+18.04) ...
Setting up libpoppler73:amd64 (0.62.0-2ubuntu2.1) ...
Setting up snapd (2.32.8+18.04) ...
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service.
Created symlink /etc/systemd/system/cloud-final.service.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service.
snapd.snap-repair.service is a disabled or a static unit, not starting it.
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for man-db (2.8.3-2) ...
Setting up libpoppler-glib8:amd64 (0.62.0-2ubuntu2.1) ...
Setting ...

BTW as I don't plan to reinstall snapd the next day I did a find

find /etc/apparmor.d/ -iname "*snap*"
/etc/apparmor.d/usr.lib.snapd.snap-confine.real
/etc/apparmor.d/cache/usr.lib.snapd.snap-confine.real
/etc/apparmor.d/local/usr.lib.snapd.snap-confine.real

and then manually deleted those files myself. This has obviously stopped apparmor complaining but it doesn't seem right I should have to do this.

The half-installed packages are probably the cause. Does anything happen if you run:

sudo dpkg --configure -a

"Does anything happen if you run:

sudo dpkg --configure -a"

Absolutely nothing. As I said I have manually removed the files, if that may affect it.

Worth noting I run Ubuntu Studio, not vanilla Ubuntu or even Xubuntu, and sometimes configuration steps may get missed by that team (eg Xubuntu is apparently back with the Synaptics pointer driver due to issues but coming from Studio I had to manually do the change to get the touchpad working properly again.) So it's possible everything is fine in the main Ubuntu version.

May 26 10:36:35 ThisOne apparmor[2850]: AppArmor parser error for /etc/apparmor.d/usr.lib.snapd.snap-confine.real in /etc/apparmor.d/usr.lib.snapd.snap-confine.real at line 11: Could not open '/var/lib/snapd/apparmor/snap-confine'

The above indicates that /etc/apparmor.d/usr.lib.snapd.snap-confine.real is still on the system but /var/lib/snapd/apparmor/snap-confine is not. Keep in mind that /etc/apparmor.d/usr.lib.snapd.snap-confine.real is a Debian conffile and therefore not removed unless --purge is specified. Since the reporter only did a remove without a purge, /var/lib/snapd/apparmor/snap-confine was removed and /etc/apparmor.d/usr.lib.snapd.snap-confine.real was not. IME, this is a bug in the snapd packaging-- /etc/apparmor.d/usr.lib.snapd.snap-confine.real should be changed from a conffile to a config file (eg, copied into place from /usr/share or somewhere instead of shipped in /etc) and /etc/apparmor.d/*snap-confine* should all be removed on remove (with or without --purge). With how snapd works with re-exec, it is almost unreasonable to expect a local admin to make changes to /etc/apparmor.d/usr.lib.snapd.snap-confine.real and expect them to last (and thus justifying changing them to config files that can just be removed on package removal).

@Dale, importantly, please keep in mind that the log message and systemd status is non-fatal: all profiles that could be loaded were loaded and you can verify this with 'sudo aa-status'. You should be able to work around this by performing 'sudo dpkg --purge snapd' which should remove the problematic profile. If it doesn't, please report back since that would indicate a bug in the packaging (and once reported, simply removed the file yourself with 'sudo rm -f /etc/apparmor.d/usr.lib.snapd.snap-confine.real').

@Jamie

Thanks, I hadn't thought of purging to try and clean up from issues like this when there's a left over file but on hearing you say it then it seems so obvious!

As I said above I manually removed the file to get apparmor loading (actually three of them in the /etc/apparmor folders) and not seen any errors since. In fact it was only by chance I saw the one that triggered by above report, I doubt the effect would have been serious enough to cause me issues from the little I understand of this package...

But again thanks, purging still seems to have removed a few bits and I will definitely remember to try it in any similar situations in the future.

~$ sudo dpkg --purge snapd
[sudo] password for dale:
(Reading database ... 402920 files and directories currently installed.)
Purging configuration files for snapd (2.32.8+18.04) ...
Final directory cleanup
Discarding preserved snap namespaces
Removing extra snap-confine apparmor rules
Removing snapd cache
Removing snapd state

Status changed to 'Confirmed' because the bug affects multiple users.

This has also bugged me for some number of months but the work around is really easy -- just use
apt purge snapd
instead of
apt remove snapd

What happens is that upon removal of the snapd package, dpkg sees that /var/lib/snapd/apparmor/snap-confine is empty and removes it which later breaks apparmor when it tries to open that directory (as referenced by /etc/apparmor.d/usr.lib.snapd.snap-confine.real at line 11 which the log clearly states).

Since usr.lib.snapd.snap-confine.real is a configuration file it does not get removed during `apt remove`

This is still broken. A key security feature of the OS breaks if you uninstall some garbage package. I wouldn't have noticed it if I hadn't seen the logs.

I have a hunch that this happens because /etc/* is marked as a configuration file and not automatically removed unless the package is purged. I think we could special case that file and remove it on regular package remove using postrm script.

Fink Nottle: AFAIK apparmor should not be breaking. The parser loads all profiles but doesn't stop on a profile that fails to load. The error message is displayed but remaining profiles are loaded anyway. It there some specific profile that you were expecting to see loaded that did not after you removed, but not purged snapd?

Zygmunt, you shouldn't override the dpkg behavior as there is an expectation on a Debian based system on how things in /etc are treated and what dpkg expects. That said, you could change the packaging in various ways. Eg, stop shipping it in /etc at all or disable the profile via /etc/apparmor.d/disable. Alternatively, don't install it to /etc, but instead /usr somewhere and during postinst use ucf or similar to copy it into place such that dpkg considers it a config file instead of a conffile (I suggest looking at the Debian policy manual on config file vs conffile).

I have an unfinished patch that moves the snap-confine apparmor profile out of /etc entirely. I will try to finish and propose it.

I ran into this issue. Workaround fixed it perfectly.

One problem is that if snapd is removed via installation of a metapackage (as in my case) then there isn't really a point where the sysadmin makes the clear choice of purging vs removing.

This bug is still biting, so I wonder if @zyga could revisit this issue.

Hi
Still have this bug on debian 10 on 2022-09-06

None of the solution provides here solve the issue, but having a deeper look into the issue show that the file which systemd report as not found is the one in /etc/apparmor.d

So to solve the issue, I made a symlink in /var/lib/snapd/apparmor/profiles to the profile file present in /etc/apparmor.d :

$ sudo ln -s /etc/apparmor.d/usr.lib.snapd.snap-confine.real /var/lib/snapd/apparmor/profiles/usr.lib.snapd.snap-confine.real

After just run :
$ sudo systemctl restart apparmor

and you get apparmor running again with no error :

$ systemctl status apparmor
● apparmor.service - Load AppArmor profiles
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2022-09-06 11:22:45 CEST; 2s ago
     Docs: man:apparmor(7)
           https://gitlab.com/apparmor/apparmor/wikis/home/
  Process: 8217 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
 Main PID: 8217 (code=exited, status=0/SUCCESS)

sept. 06 11:22:45 lap-nba.14rv.lan systemd[1]: Starting Load AppArmor profiles...
sept. 06 11:22:45 lap-nba.14rv.lan apparmor.systemd[8217]: Restarting AppArmor
sept. 06 11:22:45 lap-nba.14rv.lan apparmor.systemd[8217]: Reloading AppArmor profiles
sept. 06 11:22:45 lap-nba.14rv.lan apparmor.systemd[8217]: Skipping profile in /etc/apparmor.d/disable: usr.bin.thunderbird
sept. 06 11:22:45 lap-nba.14rv.lan systemd[1]: Started Load AppArmor profiles.

Hope it could help

regards
nbanba

Would it be possible to utilize symlinks in /etc/apparmor.d/ that point to profiles in a non-cofiguration directory but still root owned?
Then postrm could remove the real profiles thus breaking the symlinks but it appears that AppArmor is happy with ignoring broken symlinks.

Proof of Concept:

```
$ sudo ln -s /does/not/exist //etc/apparmor.d/bug1773515
$ sudo systemctl reload apparmor.service

```