Hello all - I've been sketching out an implementation of permissions. I've laid out some code framework, but wanted to through tis out for validation. Assumptions: that B2G/Firefox will have separate processes for each app/tab. This is already declared to be true (but not implemented) for B2G. This proposal doesn't required ipc , but I believe we need to support it. Also note that this should be able to replace the existing Permission and PermissionManager in gecko.
The basic idea is that there is a separate, single Process Manager that is the master owner of the permissions. It would have functions for: • testing permissions (return if permission is granted/denied, no user query) • adding/removing permissions • enumerate the permissions • query permissions (same as checking permissions, but can query the user if the state of a permission is not known, maybe take a reason to display to the user if the UI is needed needed) • support observers of permission changes. In general, the functions work with uri signatures(domain, partial URL, whatever is decided for the WebApps and permission structures. The permission structure is an extension of the existing permission structure: • type • uri signature • value • source (user, manifest, system) • expiration type • expiration time • allow message (for the UI buttons, just an ID into some string list for space and localization consideration). • deny message Each process has a similar object proxy that forwards the requests to the master process. The proxies can also implement a cache to speed up responses, and if so, observe the master so they can keep their caches coherent. These separate processes should also be responsible for populating the uri signature, so an app can't spoof it, or if the master process can determine the uri signature from the call implicitly, that would even be better. I'm also assuming that these slave processes would block on a query function. If an app really wants to continue running until a user grants permission (when it is needed), they can do the query in a separate thread. I'm also assuming that the UI for querying the user is something that runs outside the normal app/web arena so that it can't easily be subverted and also that it is NOT replaceable for the same reason. Access to controlled resources would do a check permission, to see if access is allowed. If the controlled resource is in another process, the caching mechanism would work for it as well (it would cache based on uri signature, where as UI processes would cache based on permissions.) I've been considering whether or not the master process could be partially replaced with something as simple as a sqlite3 database. The database would live in a directory with different ownership than the rest of the UI, so that the normal usage would have it opened read only. The proxy could directly query the database for testing permissions and enumerate the database without having to call the permissions API. The master process would still be used to update the permissions, signal that something changed, and invoke the UI . -Jim Straus
On Mar 13, 2012, at 1:10 PM, [email protected] wrote: > Thanks for the excellent write up Jonas. I strongly urge having permissions > being lazily granted. I believe a user installing an app will say yes to any > menu item (especially if many permissions are requested). However when they > go to use some specific functionality that requires a permission they are > more likely to say no. > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
