Comment 6 for bug 1577514

This came up again on IRC today and I wanted to point to the plan of record and noticed it didn't exist here (perhaps it is somewhere else?). I've heard this talked about in other places but didn't see the outcome explicitly listed here. AIUI, what Gustavo (please correct me if I'm wrong! :) has laid out is:

1. a generic preload library that is capable of mapping directories/files/named sockets from one place to another
2. a way to declare in the packaging yaml what should be mapped (eg, /etc/foo to $SNAP_DATA/etc/foo)
3. on application launch, the declared mappings are exported as env vars that the generic library interprets and the library is LD_PRELOADed.

In this manner there are no code changes and the packaging yaml need only be adjusted. This would allow us to easily handle Chrome and a whole bunch of other software.

As for the current situation (ie, while the above is not implemented) with shm and the chromium issue in particular, in addition to what Sergio suggested snapcraft will do for electron, snapd now has security policy to allow '/{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,' so developers are free to patch their code to make things work today regardless of open() or shm_open() usage. We've also engaged with upstream Chrome to see if they are open to adjusting the shm path (waiting to hear back). Oxide is currently being adjusted to use a path that conforms to the aforementioned allowed path.

@Jamie Bennett, it isn't clear (to me and others I've spoken to on IRC) where this should be implemented and by whom (ie, snapd vs snapcraft) and at what priority. I see Sergio is assigned, but not sure if that is for his electron work or for the generic library. Perhaps the priority of this can be discussed for a few minutes at the sprint?