[Jsprintsetup] Security Idea

Guillaume Crico guillaume.crico at gmail.com
Sun Feb 13 05:15:59 PST 2011


Hi Dimitar,

> I'm not sure only of that, is it correct to use FF permission manager 
> from our extension? Is it "frozen" as parameters of call? 
I don't know.
The nsIPermissionManager interface is defined in the "netwerk" part of 
the toolkit.
It seems that the interface is bunddled in the new/nextgen 
XPCOMUtils/Services API  (with "perms" as service name).
So I think that we can consider it as "frozen"/"ready tu use in extensions".
You just have to choose a good name for the "permission.type", in order 
not to clash with others...


For the "reusable"/"template like" permissions.xul window (and its 
"window arguments" magic), it is in the "browser" part of Mozilla.
So it is more likely to change in theory (but it didn't change, even 
from FF3.x to FF4.0b11).

The problem with permissions.xul is that you cannot use it directly as 
"optionsURL" in the install.rdf !
<em:optionsURL>chrome://jsprintsetup/content/options.xul</em:optionsURL>
and that you cannot add some other options aside the perms list (if you 
planned to add some).

So you have to do (in your options.xul):
+-------------------------------------+
| [ ] An option |
| [x] An other options    |
|                                     |
| |Manage permissions by website...|  |
+-------------------------------------+
with the "Manage permissions..." button openning the permissions.xul 
window...

But this is not so "unuseable" to have a "one more click" when using the 
"Extension options" path!
As long as the "notification" system can open the permissions.xul in one 
click...
(I started to write a options.xul by coping/pasting code from 
permissions.xul, and using permissions.js and permissionsUtils.js, but 
it's not a so good idea...)


For the "file://" problem, the "anti-popup" handler do not allow to 
store permissions, but the "allow once" entry in the notification menu 
does work. I think you can do the same, or maybe add an option checkbox 
"Allow for local files" (and check this case against the users prefs in 
your code), if you really need to support local files.

I understood that the "file://" protocol support is not a priority at 
all in the mozilla core!
More likely they plan to drop/lock webapp featuresin the future for 
"local protocol", because of security issues!
And I can understand this, even if personnaly I love "personnal html app 
in a single file".
Imagine what a dblclick on an html attachment in a mail can do with a 
"non aware" user, if the file:// protocol has privileges...
(If an "Always allow for this site" choice would add the html file 
directory, this would be the "temp/download" user dir, so every other 
temp files!)


Regards,
Guillaume Crico


Le 13/02/2011 10:02, Dimitar Angelov a écrit :
> Hi Guillaume,
>
> Thanks for the suggestions and spent time I think that I can do the 
> things and will inform you.
> I have made additional research on FF permission manager as you 
> suggested in
>    - browser.jar/content/browser/preferences/permissionsutils.js
>    - browser.jar/content/browser/preferences/permissions.xul
>    - browser.jar/content/browser/preferences/permissions.js
> I think that things may be done in very elegant manner if I use 
> permissions.xul to edit permissions. I also have made some experiments 
> and things look like to be possible. I'm not sure only of that, is it 
> correct to use FF permission manager from our extension? Is it 
> "frozen" as parameters of call?
>
> Thank you again for useful information!
>
> Regards,
>
> Dimitar Angelov
>
> On 13.2.2011 г. 01:59, Guillaume Crico wrote:
>> Hi Dimitar,
>>
>> I am honored by your enthousiam for my suggestion!
>> I did not have the time to test and read the "last version" of the
>> extension you sent. Sorry.
>>
>> > 1. I don't know how permission manager treat local uri-s?
>> I think (needs verification) that it's all domain based (eg. 
>> "uri.host").
>> So you pointed an issue!
>> https://bugzilla.mozilla.org/show_bug.cgi?id=204285
>>
>> > 2. Is it possible for manage permissions from FF permissions manager.
>> Tools|Page Info|Permissions.
>> I did not thought about it... It's a "must have"! (I hope it's easy)
>> Did you notice that local uri-s do not have any "permissions tab" in
>> "page info"?
>>
>> > 3. Are there any other tool to view and manage permissions to use for
>> debuging.
>> Permissions are stored in "permissions.sqlite", in the user profile
>> directory.
>> You can use your favorite sqlite GUI [*], or even a sqlite cli 
>> executable.
>> [*] https://addons.mozilla.org/fr/firefox/addon/sqlite-manager/
>>
>>
>> Regards,
>> Guillaume Crico
>>
>> Le 12/02/2011 13:55, Dimitar Angelov a écrit :
>> > Hi Guillaume,
>> >
>> > I want to add some thoughts to discuss after reading about
>> nsIPermissionManager.
>> >
>> > From brief documentation and after looking at source code I have some
>> conclusions (Please correct me if is wrong).
>> > 1. Permission manager is global (for FF) storage for permissions for
>> all components in FF.
>> > 2. Permissions are on host level basis and permission type.
>> > If different components in FF have different type of permissions over
>> host they must use different "type" to distinguish.
>> > For example popup manager use
>> > PermissionManager.add('http://host.tld/some/path/script.php', 'Open
>> Popup Windows', ALLOW_ACTION, EXPIRE_SESSION);
>> > to allow popups from site host.tld for the session.
>> > If jsPrintSetup want to use permission manager to add permision 
>> will be
>> > PermissionManager.add('http://host.tld/some/path/script.php',
>> 'jsPrintSetupAccess', ALLOW_ACTION, EXPIRE_NEVER);
>> > which mean that for host.tld is allowed access to jsPrintSetup fot
>> this session.
>> > 3. Checking of permission is made by calling testPermission or
>> testExactPermission for URI/permission type.
>> > 4. If jsPrintSetup want to get list of current permissions
>> (permission types specific for jsPrintSetup) there must be enumerated
>> all permissions from permission manager and filter these for 
>> jsPrintSetup.
>> > This must be used in jsPrintSetup options dialog.
>> > 5. For removing host/permission type from permission manager must be
>> user method remove(host, permission type). Where permission types are
>> only permission types for jsPrintSetup.
>> > removeAll is not applicable from this context.
>> >
>> > If we assume to use only one permission type for jsPrintSetup, for
>> example "jsPrintSetup Print Management" the solution will be simple.
>> >
>> > I missed following to the moment:
>> > 1. I don't know how permission manager treat local uri-s?
>> > 2. Is it possible for manage permissions from FF permissions manager.
>> Tools|Page Info|Permissions.
>> > 3. Are there any other tool to view and manage permissions to use for
>> debuging.
>> >
>> > If my concerns are correct I can implement this.
>> >
>> > Regards,
>> >
>> > Dimitar Angelov
>> > _______________________________________________
>> > Jsprintsetup mailing list
>> > Jsprintsetup at mozdev.org
>> > https://www.mozdev.org/mailman/listinfo/jsprintsetup
>>
>
> _______________________________________________
> Jsprintsetup mailing list
> Jsprintsetup at mozdev.org
> https://www.mozdev.org/mailman/listinfo/jsprintsetup


More information about the Jsprintsetup mailing list