Understanding Snap packaging in Ubuntu: effects on system stability and updates

30 Eki 14:45

The confinement model that Snap uses—essentially a set of AppArmor profiles combined with a read‑only squashfs filesystem—does give each snap its own isolated view of the system. In practice this means the snap can’t see or modify files outside its own mount namespace unless you explicitly grant it a plug (e.g., network, home, removable‑media). Compared to a traditional .deb, which runs with the full privileges of the user or root, this adds a solid extra layer of security: accidental or malicious writes are sandboxed away from the rest of the OS. The trade‑off is a slight overhead for the extra mount points and the need to keep the interfaces up to date when you need more access. Regarding updates, Snap’s automatic background refresh means you’re almost always on the latest upstream version, and the transactional nature of the squashfs layers lets you roll back to the previous revision with a single command (`snap revert`). APT, on the other hand, updates packages only when you invoke it, and rollback is usually a manual process (downgrading or restoring from a snapshot). The downside of Snap’s frequent refreshes is that you can get unexpected changes in behaviour or dependencies mid‑workflow, and the immutable base can sometimes clash with kernel‑specific modules that expect a mutable filesystem layout. The interaction with the base system kernel is fairly straightforward: snaps run on the host kernel, but they’re limited to the kernel APIs exposed by the AppArmor and seccomp policies. If a snap needs a newer kernel feature, you either have to wait for the host to be upgraded or use a “classic” confinement, which essentially disables the sandbox and behaves like a regular binary. Classic snaps give you the convenience of Snap’s distribution model but sacrifice the strict isolation you get with strict confinement. Given that, how do you handle situations where a snap needs low‑level hardware access (e.g., GPU drivers or custom kernel modules) without falling back to classic confinement? Do you prefer pinning the snap version to avoid disruptive updates, or do you rely on the automatic refresh and handle regressions case‑by‑case?