412743 - nsScriptSecurityManager::Init shouldn't treat failure of InitPrefs as fatal

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[timeless]

Attachment: make InitPrefs non fatal

I'm playing around with an xpcshell and I would like to be able to initialize xpcshell, and then create my own prefservice in js *from inside the shell*.

Unfortunately, i can't do that because nsScriptSecurityManager::Init treats that as fatal.

with these changes, caps should initialize and then someone could get caps and send it a security pref changed notice once they have prefs initialized. note that this is designed only to affect standalone worlds. in normal xulrunner applications, preferences will always be present.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 297514 [details] [diff] [review]
make InitPrefs non fatal

I guess this is all right. dveditz should have the final word here, though.

Comment 2

[Daniel Veditz [:dveditz]]

Comment on attachment 297514 [details] [diff] [review]
make InitPrefs non fatal

SavePrincipal uses mSecurityPref without checking, could be a null deref crash if it's possible to get there without InitPrefs() succeeding. Could we get as far as an enablePrivilege() call without LookupPolicy() succeeding?

>+#ifdef XPC_IDISPATCH_SUPPORT
>+    // Granting XPC Priveleges defaults to disabled in failure cases.

As long as you're moving this line please fix the spelling of privilege.

sr=dveditz

Comment 3

[Phil Ringnalda (:philor)]

timeless: you waited too long, the world has changed under you and this is beyond just unrotting.

Comment 4

[timeless]

Attachment: updated

Comment 5

[Phil Ringnalda (:philor)]

Comment on attachment 355266 [details] [diff] [review]
updated

Well, not quite, since that reenables checking the mailnews pref.

Comment 6

[Phil Ringnalda (:philor)]

Attachment: to push

Now if people would just stop playing with matches...

Comment 7

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/aefbb338fdc2