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.
- PostgreSQL.* # import any shared memory file matching `/dev/shm/PostgreSQL.*` from the host
- pulse-shm-* # import pulse shared memory from the host
- 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
/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
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.