Concurrent activity instances
Situation: #5476
Browse is a web-browsing activity that is currently implemented on top of Mozilla's gecko and nss libraries. Unfortunately, these libraries create files in a profile directory with very restrictive permissions. This means that Browse may work beautifully the first time it is run and may fail miserably on the second when it finds itself unable to manipulate shared resources like its webcache, certificate database, and so on.
General Solutions
There are several ways to solve this problem, including:
- Patch the Mozilla libraries so that they respect our choice of umask.
- Patch the Mozilla libraries by adding a configuration option that indicates appropriate file creation permissions.
- Use an LD_PRELOAD wrapper to impose appropriate permissions on the libraries.
- Use the libraries as-is and attempt to clean up the permissions after the fact, either in the activity itself or in the shell.
- Create an adapter library which, under the control of the activity, will synchronize sanitized versions of the profile directory with other activity instances.
General Plan
Solutions which can be sent upstream are clearly preferable in the long term but we are unsure of how to approach the upstream maintainers.
In the mean time, we intend to use the adapter library approach because we think it is the safest choice (i.e. the least prone to race conditions, privilege-misuse, and unintended side-effects) available that will satisfy our schedule.
Detailed Solution
There are many choices to make when designing an adapter library. In particular - which of the attributes of 'atomic', 'consistent', 'isolated', and 'durable', are necessary?
Atomicity and consistency are fairly easy to achieve by themselves with careful manipulation of of the filesystem. Isolation and durability require more thought because they require that contention be either resolved (e.g. by merging) or avoided (e.g. by careful naming).
At present, we believe that atomicity and consistency are sufficient for solving Browse's permissions issues because Browse already uses a locking scheme to attempt to ensure that only one Browse process will be running at the same time. In more detail: Browse's locking scheme should allow us to avoid having to merge profiles by forcefully ensuring that updates are made to only one profile at a time.