Cannot remove Apparmor rule after adding it to a snap

snapd
1

I verify that Firefox cannot read ~/.profile. I edit /var/lib/snapd/apparmor/profiles/snap.firefox.firefox to include

owner @{HOME}/.profile r,

I restart Firefox and confirm it can now read ~/.profile.

I change my mind and delete that line.

Expected: Firefox can no longer read ~/.profile.

Observed: Firefox can still read ~/.profile.

apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.firefox.firefox

does not help.

What am I doing wrong?

2

Could you confirm this persists after a reboot?

I don’t think you actually even need to restart Firefox for the AppArmor rules to have an effect, the rules can be updated whilst the app is running; although snapd was engineered to explicitly not do that after complaints reloading the AppArmor profile mid session can cause crashing.

It might be worth giving snapd a nudge to regenerate the profile itself, you could potentially do something like

sudo snap disconnect firefox:home
sudo snap connect firefox:home

so that it re-generates the config.

1 Like
3

It does not persist after a reboot.

I don’t think you actually even need to restart Firefox

Today restarting Firefox actually didn’t help, only apparmor_parser did.

Disconnecting and reconnecting the interface did it, though. Thank you!

Still, I wish working with snaps were more consistent and documented. I’m pretty sure the apparmor_parser did the trick before, and now I see there is a new variable: a internal parser apparmor:parser:snapd-internal (here it is not enabled). It does not inspire confidence that the magic trick used today will work tomorrow.

4

And it should not, apparmor is an implementation detail after all, all handling of it happens dynamically and automated, which is why you should not actually tinker with it unless when developing a snap interface… interfaces are the actual standardization, not apparmor, seccomp and friends… i.e. we might at any time switch transparently from apparmor to $next_great_thing and you wouldn’t notice that on the interface level…

5

That’s actually the case, I was testing to extend an existing interface. I don’t know the intricacies of how this is implemented and I don’t think it is inviting (and to be clear, nor that it was here suggested) to require that from contributors.

So if the only reliable way of doing this is rebooting after each change, it should be documented, perhaps in interfaces/HACKING, but somewhere. I’d gladly to submit a merge request for that, if desired.

1 Like