Issues with Sharing User Profiles in Mozilla
This page introduces the topic of profile sharing and goes through the different
components affected by moving to a shared profile environment. Work has begun
on the design for a mechanism to share prefs between multiple mozilla/gecko
based processes. For design and implementation notes please visit the Profile Sharing Tech Documents Home PageThere's been much discussion on profile sharing (or lack there of) in http://bugzilla.mozilla.org/show_bug.cgi?id=76431 and the general consensus is that it's a bad idea to share profiles between:
* Multiple instances of the same application
* Instances of different applications at the same time.
Mozilla does not currently have a scheme in place to arbitrate safe access to a profile between different applications. So, the general issue with sharing the same Mozilla profile between different instances of Mozilla based applications simultaneously is the serious and likely possibility of file corruption.
Modules affected by multiple instances/apps sharing the same profile:
Bookmarks
Cache
Mail/News
Preferences
History
Certificates
Cookies
Plugins
Password Mgr/Form Prefill
Even though all of the modules mentioned above will be affected in some way in a shared profile environment, the following modules will be of particular interest to users embedding Mozilla:
Cookies
Cache
Certificates
Plugins
Preferences
Password Manager
Cookies
Currently the Cookies module writes to disk frequently since it does not want to lose a cookie due to application crash. It currently writes to disk every timea cookie is set.
Even though cookies are written out to the file, the browser only reads in the file once (at the beginning of the session) so if one app changes it other apps will not know that.
The primary issue here is that of sharing in-memory session cookies between multiple application instances.
If this were to become a requirement for shared profiles then we need to devise a complex IPC scheme to communicate session cookie information to all currently running instances of Mozilla which are sharing a profile.
Cache
The primary issue here is that of cache corruption since multiple instances will be trying to update the cache folder simultaneously.
Major rewrite (and re-architecture) of the Cache module will be required to share the same Cache directory in a profile between different instances of a Mozilla based application. There are major file sync issues involved here and in the event of a rewrite (if really needed) there's a serious chance of cache performance degradation.
Recommendation : Do not share the same cache directory between different instances.
A solution to work around this is that each application create its own cache dir per profile via a preference setting. This could be done with the current code base.
Certificates
The certificate database is an old Berkeley binary database, that gets updated as the application runs. The version of Berkeley DB we're using does not support concurrent access from multiple applications. The application keeps handles to the open files, and makes assumptions about the current state of the database.
Multiple applications accessing that database would lead to corruption immediately.
The security team is looking into supporting concurrency for some of their clients (servers have been wanting this for a long time), but it will require using a newer version of the Berkeley DB. These new versions are controlled by Sleepy Cat for commercial releases. We cannot open source the DB, so it is unlikely that Mozilla will be able to use this work.
Note: the above paragraph doesn't seem right to me. SleepyCat claims to be open source and allows shipping as part of any application for which the source code is available. See their license page. Well? That seems like it's compatible with our releases, doesn't it? -- scc
Plugins
The issue here is that some plugins such as Flash that require stream-as-file wouldn't work. These type of plugins utilize the cache, if present. If the disk cache is not present, the plugin code will fallback to storing the downloaded data to a temporary folder. We'd need to verify that this temporary folder uses the appropriate system call to generate a unique file.
That being said, if we go with the recommended "cache" solution, this issue becomes somewhat moot, since there would be a disk cache for each application.
Also, we encounter issues such as notification of a newly installed plugin in one instance to all other currently running instances.
We encounter a similar notification issue with the notification of new XPCOM component installation across application instances as well.
Preferences
Currently preferences get written out at application shutdown. So, the last instance which shuts down wins.
The likelihood of preference corruption only occurs when preferences are modified by individual simultaneously running instances. We do not have an issue in the scenario of "master application" used to set preferences while other "companion" applications merely read the preference settings.
Password Manager
Currently the Password Manager module writes to disk frequently since it does not want to lose a password due to application crash i.e. it currently does an immediate write to disk. But, it reads it only at the beginning of the session,
so, if one app changes some values other apps will not know about it.
A proposed solution to the "Shared Profile" issue
Many ideas were floated around on ways to solve this issue. Most of them involved some sort of an XP IPC mechanism to notify/arbitrate access to shared resources in a profile between multiple running instances of applications. The complexity and the amount of work involved with this approach did not make this route an ideal one to pursue.
A notion of a "subprofile" was discussed which would allow each running instance to have its own prefs, cookies, cache settings - all under the same profile. Upon startup each process would create a separate dir for prefs, cache etc. under the same profile. Each process would also be able to access any "master profile" data, say a "global" preference setting, if needed. We can also extend the observer mechanism currently in place to have another profile
observer which watches changes to the master profile dir and notifies the other interested parties (i.e. application instances) so they can act appropriately.
Irrespective of the route we take, we would need to add support for monitoring/communicating file changes across processes in an XP way. It's unclear what this would exactly mean, but whatever it ends up meaning it would most likely be reused for many of the profile elements.