Closed Bug 261339 Opened 20 years ago Closed 20 years ago

Setting capability.policy.default.Window.top to noAccess seems to crash mozilla

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: timeless, Assigned: timeless)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: crash)

Attachments

(1 file)

if mPolicyPrefsChanged then InitPolicies() will stomp over aPrincipal,mSecurityPolicy
1.29 KB, patch
caillon
: review+
dveditz
: superreview+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040922

1. load about:config
2. right click the list
3. select new > string
4. capability.policy.default.Window.top<enter>
5. noAccess<enter>
6. right click the list
Whiteboard: tb961187h tb961188e tb961189y
Stack Signature	 0x09d1265d be0728b2
Product ID	MozillaTrunk
Build ID	2004092206
Trigger Time	2004-09-23 22:15:41.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	about:config
User Comments	right click new>string capability.policy.default.Window.top
noAccess ok right click
Since Last Crash	35460 sec
Total Uptime	115681 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x09d1265d
nsScriptSecurityManager::LookupPolicy 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1005]
nsScriptSecurityManager::CheckPropertyAccessImpl 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 618]
nsScriptSecurityManager::CheckPropertyAccess 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 475]
nsScriptSecurityManager::CheckObjectAccess 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 459]
js_InternalGetOrSet 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1417]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2711]
JS_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
2554]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1316]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
PrepareAndDispatch 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 119]
SharedStub 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsXULElement::IsFocusable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1441]
nsIFrame::IsFocusable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrame.cpp,
line 4551]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 1874]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5982]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5814]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2300]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2030]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 168]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1078]
nsWindow::DispatchWindowEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1095]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5348]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5600]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 4106]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1356]
USER32.dll + 0x8709 (0x77d48709)
USER32.dll + 0x87eb (0x77d487eb)
USER32.dll + 0x89a5 (0x77d489a5)
USER32.dll + 0x89e8 (0x77d489e8)
nsAppShell::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 489]
main1 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1331]
main 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1802]
WinMain 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1828]
WinMainCRTStartup()
kernel32.dll + 0x16d4f (0x7c816d4f)

all three stacks are approximately the same, the last one has one frame between
#0 and what the others have as the tail:

PL_DHashTableOperate 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/ds/pldhash.c,
line 491]
Keywords: stackwanted, talkbackid
Whiteboard: tb961187h tb961188e tb961189y
Assignee: nobody → timeless
Status: UNCONFIRMED → ASSIGNED

    
  

        Attachment #163675 -
        Flags: superreview?(brendan)

        Attachment #163675 -
        Flags: review?(caillon)

    
    

    
  
Comment on attachment 163675 [details] [diff] [review]
if mPolicyPrefsChanged then InitPolicies() will stomp over aPrincipal,mSecurityPolicy

This looks right from my reading over the code in InitPolicies()

        Attachment #163675 -
        Flags: review?(caillon) → review+

    
    

    
  
Comment on attachment 163675 [details] [diff] [review]
if mPolicyPrefsChanged then InitPolicies() will stomp over aPrincipal,mSecurityPolicy

Looks OK-ish. My worry is that if InitPolicies() is trashing the policy on
*this* principal, we've just trashed all the other principals held elsewhere in
the code.

I need to satisfy myself that this is OK first

        Attachment #163675 -
        Flags: superreview?(brendan) → superreview?(dveditz)

    
    

    
  
Comment on attachment 163675 [details] [diff] [review]
if mPolicyPrefsChanged then InitPolicies() will stomp over aPrincipal,mSecurityPolicy

OK, that's the only call to GetSecurityPolicy, but there are several ways into
LookupPolicy. I think you'll crash after this on other principals.

IIRC capability prefs were originally designed to be set at startup and left
alone. That's still true in normal use (though not with the "Zone" setting
designs people are trying to come up with) so I guess I won't worry too much
about crashes hiding behind this one.

        Attachment #163675 -
        Flags: superreview?(dveditz) → superreview+

    
    

    
  
mozilla/caps/src/nsScriptSecurityManager.cpp 	1.242
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: