Strict snaps on Debian prefer system-installed tools over the ones in the snap

[Kyle Fazzari]

The Nextcloud snap runs great on Ubuntu, but on Debian, running `mysql` in the snap seems to run mysql from the system (if it's installed), which is very problematic. How is that even possible given the pivot root?

Here are a few relevant bugs:

https://github.com/nextcloud/nextcloud-snap/issues/819
https://github.com/nextcloud/nextcloud-snap/issues/733
https://github.com/nextcloud/nextcloud-snap/issues/913

Not everyone mentioned their Debian version, but one who did mentioned Sid.

[Zygmunt Krynicki (zyga)]

This feels like a serious issue. One possibility is snap-confine misunderstanding the distribution and believing it is running on a core16 system. I asked on IRC but I will still check manually myself, if you can provide the information about the release of debian that you used.

[Kyle Fazzari (kyrofa)]

I know at least one was on sid: https://github.com/nextcloud/nextcloud-snap/issues/913#issuecomment-504719193

[patman (patmans)]

I hit this on Fedora 29, using the nextcloud snap.

Are there any workarounds for this?

Thanks ...

[Kyle Fazzari (kyrofa)]

Zygmunt, latest comment from another Nextcloud snap user (https://github.com/nextcloud/nextcloud-snap/issues/913#issuecomment-537892194):

$lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch

I can confirm that, after removing and purging every myslq and mariadb packages, I was able to install and configure nextcloud using snap.

[Zygmunt Krynicki (zyga)]

We've discussed this issue and determined the following:

 - the issue affects Debian and systems like it but not Ubuntu
 - the issue is caused by mysql reading the host's /etc/mysql configuration
 - on Debian this is not denied by apparmor
 - on Ubuntu this is denied by apparmor and the additional configuration set up by the snap is effective

The issue, as described by the bug title is not real but I acknowledge there is another issue with confinement. We've decided not to enable partial apparmor on existing Debian releases. We plan to enable it on the next stable release, where people need to explicitly upgrade and accept the consequences of the new behaviour. While it affects nextcloud negatively, we don't want to break existing installations where snaps worked because confinement was lax in Debian, but gets stronger to the point of breaking without those people upgrading their Debian installations explicitly.

[BeSt (steph-belardi)]

I understand the reason of why.
As a not-so-expert user, can you (or someone) explain which are the workarounds possible before next stable release? Like enable apparmor and if so, how to do it?

Thank you in advance.

[Kyle Fazzari (kyrofa)]

As a snap developer, I am displeased that snapd's failing to provide consistent behavior across distros is considered invalid. The burden of ensuring snaps run properly across distros should not be left up to individual snap developers when that is one of the primary selling points of snapd.