Here is the problem: chromium content api hard codes /dev/shm/.org.chromium.Chromium.XXXX (where 'XXXX' is tmpfile-style name). There are many consumers of the chromium content api (eg, electron, oxide-qt, webbrowser-app, Google Chrome, Opera, chromium, etc).
Discarded possible solutions include:
1. force patching
2. allow all apps to access .org.chromium.Chromium.*
3. allow only one snap to access the path
For '1', asking developers to patch chromium to 's/\.org\.chromium\.Chromium/snap.$SNAP_NAME/' would be onerous and unfriendly. '2' does not provide proper application isolation and snaps could access each other's data and '3' means you couldn't have say, an electron app and Chrome installed at the same time.
Zygmunt created a PoC LD_PRELOAD library for shm_open() as an exploration into the problem space and should work well for shm_open() users, but chromium content api uses open() for portability reasons so the LD_PRELOAD library should also handle open(), doing a check to see if the requested path to open matches /dev/shm/.org.chromium... (should also handle /run/shm!) then to replace it with /dev/shm/snap.$SNAP_NAME.org.chromium... to conform to the new snappy architect-approved shm paths.
Gustavo and I discussed this on IRC today.
Here is the problem: chromium content api hard codes /dev/shm/ .org.chromium. Chromium. XXXX (where 'XXXX' is tmpfile-style name). There are many consumers of the chromium content api (eg, electron, oxide-qt, webbrowser-app, Google Chrome, Opera, chromium, etc).
Discarded possible solutions include: Chromium. *
1. force patching
2. allow all apps to access .org.chromium.
3. allow only one snap to access the path
For '1', asking developers to patch chromium to 's/\.org\ .chromium\ .Chromium/ snap.$SNAP_ NAME/' would be onerous and unfriendly. '2' does not provide proper application isolation and snaps could access each other's data and '3' means you couldn't have say, an electron app and Chrome installed at the same time.
Zygmunt created a PoC LD_PRELOAD library for shm_open() as an exploration into the problem space and should work well for shm_open() users, but chromium content api uses open() for portability reasons so the LD_PRELOAD library should also handle open(), doing a check to see if the requested path to open matches /dev/shm/ .org.chromium. .. (should also handle /run/shm!) then to replace it with /dev/shm/ snap.$SNAP_ NAME.org. chromium. .. to conform to the new snappy architect-approved shm paths.