David, Should we move this to a bug ? If so do you have a feeling for the priority level.
Do you have a feeling for which api's spawn processes ? -David ----- Original Message ----- From: "David Chan" <dc...@mozilla.com> To: "David Clarke" <dcla...@mozilla.com> Cc: qa-...@mozilla.org, dev-b2g@lists.mozilla.org, "Martijn" <martijn.mart...@gmail.com> Sent: Friday, September 28, 2012 3:36:11 PM Subject: Re: [b2g] A draft on Mochitest permissions testing in b2g I've been running my tests with OOP disabled due to earlier problems. I just tried with OOP enabled and my tests failed spectacularly, though different errors. I don't know of a way around the AppProcessPermissions check. I'll follow up with cjones to figure out how the multiprocess stuff works. David ----- Original Message ----- > From: "David Clarke" <dcla...@mozilla.com> > To: "David Chan" <dc...@mozilla.com> > Cc: qa-...@mozilla.org, dev-b2g@lists.mozilla.org, "Martijn" > <martijn.mart...@gmail.com> > Sent: Friday, September 28, 2012 2:56:49 PM > Subject: Re: [b2g] A draft on Mochitest permissions testing in b2g > > @David, > I was just out to update the thread with some added information. > I noticed that there is a second process that is running and kills > processes which have been spawned by apps that don't have the > correct permissions. > ->AppProcessPermissions.cpp > > AppProcessPermissions uses a different mechanism to determine the app > origin than the rest of the permissions code. Inside the mochitest > what I am seeing currently when I am testing a dom api that spawns > off processes to talk to the android subsystem. The permission > manager grants permission, but AppProcessPermissions kills the > spawned processes. > > .... > id failed pid:482 errno:10: file > /media/b2g/B2G/gecko/ipc/chromium/src/base/process_util_posix.cc, > line 260 > [Parent 438] WARNING: waitpid failed pid:482 errno:10: file > /media/b2g/B2G/gecko/ipc/chromium/src/base/process_util_posix.cc, > line 260 > > Do you have an example of a test case that circumvents this security > measure. > Because when I instrumented AppProcessPermissions via AppsUtils.jsm. > The origin that keeps coming up is not the app from the iframe, but > the system gaiamobile app. > > ex: > I/Gecko ( 441): origin = app://system.gaiamobile.org > I/Gecko ( 441): appId = 4 > > Do you have any examples how we can get AppProccessPermissions to > retrieve the app that we loaded in the iframe. > > The example I am working with here is: > https://github.com/dclarke/webapi-smoke-sprint/blob/master/sms/test_launcher.html > > @Martin, > PushPref is different from Permissionsdb. The permissions db is > set to be asynchronous, so even when the INSERT statement has > returned there is no way to guarantee that the next read will pick > it up. > If you see the gecko/extensions/cookie/nsPermissionManager.cpp > So it turns out yes / no, on the iframe bit. It is enough in some > cases, and not enough in others, as demonstrated above. > > > -David > > ----- Original Message ----- > From: "David Chan" <dc...@mozilla.com> > To: "Martijn" <martijn.mart...@gmail.com> > Cc: qa-...@mozilla.org, dev-b2g@lists.mozilla.org, "David Clarke" > <dcla...@mozilla.com> > Sent: Friday, September 28, 2012 12:17:17 PM > Subject: Re: [b2g] A draft on Mochitest permissions testing in b2g > > In order for an iframe to be consider a webapp, it needs to > have mozbrowser and mozapp set. mozapp must point to a valid > manifestURL, though that isn't a high bar since all installs > of app X from market Y will likely have the same manifestURL. > The real protection comes from the mozbrowser attribute which > requires the "browser" permission. [1] mochitests should be enabling > "dom.mozBrowserFramesEnabled" and adding the "browser" permission. > > I'm not familiar with the "settings" permission. It may be an older? > permission that allowed creation of app frames. > > There are additional restrictions now with bug > https://bugzilla.mozilla.org/show_bug.cgi?id=773886 > > so that only privileged principals and apps with "webapps-manage" > can load app:// > > > David > > [1] - See GetReallyIsBrowser and GetAppManifestURL > http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsGenericHTMLFrameElement.cpp#271 > > ----- Original Message ----- > > From: "Martijn" <martijn.mart...@gmail.com> > > To: "David Clarke" <dcla...@mozilla.com> > > Cc: qa-...@mozilla.org, dev-b2g@lists.mozilla.org > > Sent: Friday, September 28, 2012 10:35:48 AM > > Subject: Re: [b2g] A draft on Mochitest permissions testing in b2g > > > > On Fri, Sep 28, 2012 at 1:09 AM, David Clarke <dcla...@mozilla.com> > > wrote: > > > > > Hey B2G Devs, > > > > > > I was putting together a how to document for testing permissions > > > using > > > mochitests on the b2g emulator platform. > > > > > > https://etherpad.mozilla.org/b2g-mochitest-permissions > > > > > > Generally looking to solicit ideas and create a conversation > > > before > > > I put > > > it to the wiki. > > > > > > I would like to gather further information: > > > > > > #1) Permissions notifications > > > > > > Are there any thoughts on having a notification mechanism that > > > allows for > > > permission changes to be handled more dynamically. > > > Without permissions notifications is there any real guarantee > > > that > > > an app > > > has been installed correctly ? > > > #2) Other Mechanisms for launching permissions tests. > > > Are there any other known working mechanisms for launching > > > permissions > > > tests, or modififying app permissions. > > > > > > #3) Could there be a better mechanism for installing an app with > > > the > > > correct permissions and then running tests within that context ? > > > > > > Would anyone want to see an example where we install an app with > > > specific > > > permissions, and then run tests from within that context ? > > > > > > > > > Thanks for the feedback. > > > > > > > > > > Hi, > > > > I don't understand how something like this would work? > > https://github.com/geoelectric/webapi-smoke-sprint/blob/master/settings/test_launcher.html > > Are regular mochitests allowed to load a webapp in an iframe, just > > by > > adding the 'webapp' attribute? > > So normal websites can do the same too, then, right? > > And there is not a security problem with that? > > Anyway, it's cool that it works! > > > > About the Permissions notifications issue, that is > > https://bugzilla.mozilla.org/show_bug.cgi?id=685652 as David Chan > > mentioned. > > It needs a similar treatment as the PushPrefEnv patch. > > A workaround that probably can be used, is adding a lame > > setTimeout(nextTest, 0). That worked with the pref setting before > > the > > PushPrefEnv patch, iirc. > > > > Regards, > > Martijn > > > > > > > -David > > > _______________________________________________ > > > Qa-b2g mailing list > > > qa-...@mozilla.org > > > https://mail.mozilla.org/listinfo/qa-b2g > > > > > > > > > > > -- > > Martijn Wargers - Help Mozilla! > > http://quality.mozilla.org/ > > http://wiki.mozilla.org/Mozilla_QA_Community > > irc://irc.mozilla.org/qa - /nick mw22 > > _______________________________________________ > > dev-b2g mailing list > > dev-b2g@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-b2g > > > _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
