Hi,
can can verify on bullseye that this particular test case is not present anymore: ---8<------8<------8<------8<------8<------8<------8<------8<--- $ snap run hello-world.evil Hello Evil World! This example demonstrates the app confinement You should see a permission denied error next /snap/hello-world/29/bin/evil: 9: /snap/hello-world/29/bin/evil: cannot create /var/tmp/myevil.txt: Permission denied $ snap debug confinement partial $ snap debug sandbox-features apparmor: kernel:caps kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:cap-audit-read parser:cap-bpf parser:qipcrtr-socket parser:unsafe policy:default support-level:partial confinement-options: classic devmode dbus: mediated-bus-access kmod: mediated-modprobe mount: layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation seccomp: bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif udev: tagging ---8<------8<------8<------8<------8<------8<------8<------8<--- However, I do agree with the assessment of Mattia that this should be treated as a security issue. Users expect from snap (just like from flatpak) that there is a process confinement in place that limits the exposure of the filesystem access and APIs to running snaps. That is a central design feature, and according to the principle of least astonishment I'd expect snap in Debian to behave the same, or at least very prominently warn about it. Greetings, Lee
