In bug 1143607 it was discovered that, when Webapps.jsm collects permissions from B2G preinstalled privileged apps into the permissions DB (on first boot or after a system update) and sets the pref dom.apps.reset-permissions to true to indicate that that's been done, the pref is written to storage before permissions.sqlite is. This leaves a window where, if there's a hard reboot or an OS crash or power loss, preinstalled apps can lose their permissions — which can brick the phone, if the system app is affected. This was a big enough problem to notice because permissions.sqlite isn't being fsync()ed, which extends the race window a lot, but more generally the permission manager doesn't guarantee durability of permission updates – it runs them asynchronously on a background thread and doesn't expose any way to wait for completion. That may need to change (e.g., adding a method to run a callback when all previous permission updates are committed to stable storage) to completely fix this. This might affect B2G only, but I don't know this part of things well enough to be sure it's not relevant to desktop somehow; adjust bug flags as needed. There's more discussion of the permission DB with respect to durability vs. performance in bug 1157950 and bug 1165121.
I guess I'm affected by this bug, too. I'm building B2G simulator from gecko-dev as well as a custom Gaia profile. The first time the simulator runs well. With clicking on the close button and running the simulator again, it stucks at the Foxfood logo. If I remove the line following line: user_pref("dom.apps.reset-permissions", true); from profile/pref.js, the simulator runs well again. I dont's see a permission.sqlite in my profile/ folder all the time. I'm on Arch Linux x86_64.
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.