Currently we have very strict rules on the names of files a snap may create in /dev/shm. This generally means that applications either need to have a special case carved out such as in the browser-support interface, or need to be rewritten to accommodate the strict naming requirements.
- For closed-source applications where the packager is not upstream, rewriting the application is impossible.
- For closed-source applications where the packager is the upstream, rewriting the application is difficult to impossible or undesirable.
- For open-source applications this likely means carrying a delta unless upstream are willing to include and maintain a snap-specific patch in their source tree.
As the intention of snaps is to allow applications to work with no modifications, then I propose that snapd implements a new namespace for each snap so that they have their own /dev/shm directory similar to how we namespace /tmp (probably a different mechanism though).
Moby, the upstream of the Docker product does /dev/shm namespacing so this is definitely possible to achieve.
Snaps should then be able to opt-into importing subsets of the /dev/shm from the system, or exporting parts of their namespaced /dev/shm back to the system, and other snaps may consume the exports from one snap directly or from the host system’s /dev/shm. This will require a new plug and slot pair to provide both sides, the export and the import, for snaps to define subsets for exporting and importing.
plugs:
shared-memory:
interface: shm
name: shared-memory-export
paths:
- PostgreSQL.* # import any shared memory file matching `/dev/shm/PostgreSQL.*` from the host
- pulse-shm-* # import pulse shared memory from the host
slots:
shared-memory:
interface: shm
name: shared-memory-import
paths:
- com.google.Chrome.* # export standard google chrome shared memory thingy
- .com.google.Chrome.* # export a hidden variant of above
- org.chromium.* # chromium variant of above
- .org.chromium.* # hidden chromium variant
- .io.nwjs.* # nwjs
apps:
some-app:
plugs:
- shared-memory
Once namespaced /dev/shm support is implemented in snapd we will be able to allow browsers to not need the transitional interface browser-support and proprietary applications will be able to make whatever names they desire. Only when they export or import do we need to worry about naming. If the exports and imports are purely for the snap world then we can rename them as we need to prevent one snap trampling on another by both exporting the same names - the idea is that when we export from a snap then .io.nwjs.foo becomes snap.snapname.io.nwjs.foo on the host, but .io.nwjs.foo when used inside another snap.
For the purposes of completion the apparmor rule should allow permissions of mrw, on the shared memory exported and imported. These interfaces should not be automatically connected, and require a manual review.
Thoughts?
- we can drop that part of the proposal for now and think about just isolating