snapd no longer detects apparmor changes on upgrade

Bug #1569581 reported by Jamie Strandboge
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
High
Zygmunt Krynicki
apparmor (Ubuntu)
Triaged
High
Jamie Strandboge
Xenial
Triaged
High
Jamie Strandboge
snapd (Ubuntu)
Fix Released
High
Unassigned
Xenial
Triaged
High
Unassigned

Bug Description

snappy in 16.04 used to compare /usr/share/snappy/security-policy-version and /var/lib/snappy/security-policy-version on boot to see if the apparmor package changed and therefore if it needed to regenerate all snap policy. This functionality was recently removed with nothing added to replace it.

snapd must have a means to detect changes to the parser or the abstractions which the snap may #include, otherwise we cannot deliver parser and policy fixes from apparmor to installed snaps. It is fine to use a different method than what we had before, but we need to have something.

Changed in snapd (Ubuntu):
importance: Undecided → High
Changed in snappy:
importance: Undecided → High
description: updated
Michael Vogt (mvo)
Changed in snappy:
milestone: none → sru-1
milestone: sru-1 → sru-2
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

I discussed this issue with Gustavo and we think that apparmor itself should detect this and re-load all profiles when a change to any of the parsers or templates occurs. From snappy's POV we will re-load all profiles for a specific snap each time something in that snap changes *AND* we promise to detect changes to the internal templates built into snappy. We would not like to detect changes to apparmor itself as that can be done by a systemd job shipped with apparmor. That job should simply compile and re-load all the profiles stored in a standard directory (or have a way for snappy to tell apparmor that it stores profiles in a non-standard directory).

What do you think?

Michael Vogt (mvo)
Changed in snappy:
status: New → Triaged
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

If you want apparmor to handle it, then it can do essentially what snappy was doing before by tucking away the version somewhere in its packaging and comparing it to a cached version somewhere on the device.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ok, I've added an apparmor task and assigned to me. Leaving the snappy tasks open for "we will re-load all profiles for a specific snap each time something in that snap changes *AND* we promise to detect changes to the internal templates built into snappy" where I understand the first part is done but the changes to internal templates is not. Assigning zyga for the time being-- please adjust as necessary.

Changed in snapd (Ubuntu):
status: New → Triaged
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in snapd (Ubuntu Xenial):
status: New → Triaged
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in snapd (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in snapd (Ubuntu Xenial):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in apparmor (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in apparmor (Ubuntu Xenial):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in apparmor (Ubuntu):
status: New → Triaged
Changed in apparmor (Ubuntu Xenial):
status: New → Triaged
Changed in snappy:
assignee: nobody → Zygmunt Krynicki (zyga)
Changed in apparmor (Ubuntu):
importance: Undecided → High
Changed in apparmor (Ubuntu Xenial):
importance: Undecided → High
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

This is now done in 2.23

Changed in snappy:
status: Triaged → Fix Released
Changed in snapd (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.