mozilla crashes on open file for unpriv users

VERIFIED FIXED in mozilla0.9.7

Status

Core Graveyard
File Handling
--
critical
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: Wayne Sewell, Assigned: Brian Ryner (not reading))

Tracking

({crash})

Trunk
mozilla0.9.7
All
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
When an unprivileged user uses open file, he has no problem accessing files
in his own directory.  However, if he uses the ".." button to go up a level,
this often results in an attempt to access the root directory of the disk
([000000]).  This is normally not world-readable, so unprivileged users do not
have access to it.  However, instead of failing because of file protection, 
the open-file popup just hangs.

Updated

16 years ago
Severity: normal → critical
Keywords: hang
-> File Handling
Component: Browser-General → File Handling
.
Assignee: asa → law
QA Contact: doronr → sairuh

Comment 3

16 years ago
Since this is OpenVMS, I will debug to find out what's going on. 
Assignee: law → colin

Comment 4

16 years ago
Reproduced on M0.9.5. It hangs at [000000] if you don't have privs. Its not 
consuming any CPU though.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 5

16 years ago
Same problem on my Linux box. From root I created /home/secret and then did a
chmod 700 on /home/secret. Running mozilla from something other than root, Open
File and .. up to the top and then into /home, then selected secret. It hung.

Changing O/S from OpenVMS to Linux, so that people aren't put off of trying to
fix it!
Assignee: colin → law
Status: ASSIGNED → NEW
OS: OpenVMS → Linux
Hardware: DEC → All
bryner?
Assignee: law → bryner
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
(Assignee)

Comment 7

16 years ago
We now _crash_ in this situation... 
Keywords: hang → crash
Summary: mozilla sometimes hangs on open file for unpriv users → mozilla crashes on open file for unpriv users
yep. here's takback info #38296372:

Stack Signature  nsFileView::SetDirectory() c22ff26e
Build ID 2001112008
Product ID MozillaTrunk
Operating System LinuxIntel
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
nsFileView::SetDirectory()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEventWithTarget()
nsEventStateManager::CheckForAndDispatchClick()
nsEventStateManager::PostHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x40347d7f)
libglib-1.2.so.0 + 0x11773 (0x4037a773)
libglib-1.2.so.0 + 0x11d39 (0x4037ad39)
libglib-1.2.so.0 + 0x11e1e (0x4037ae1e)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
GlobalWindowImpl::OpenInternal()
GlobalWindowImpl::OpenDialog()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXPTCStubBase::Stub12()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsXBLPrototypeHandler::ExecuteHandler()
nsXBLWindowHandler::WalkHandlersInternal()
nsXBLWindowKeyHandler::WalkHandlers()
nsXBLWindowKeyHandler::KeyPress()
nsEventListenerManager::HandleEvent()
nsXULDocument::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleChromeEvent()
GlobalWindowImpl::HandleDOMEvent()
nsDocument::HandleDOMEvent()
nsGenericElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::OnInput()
handle_key_press_event()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x40347d7f)
libglib-1.2.so.0 + 0x11773 (0x4037a773)
libglib-1.2.so.0 + 0x11d39 (0x4037ad39)
libglib-1.2.so.0 + 0x11eec (0x4037aeec) 
(Assignee)

Comment 9

16 years ago
Created attachment 59250 [details] [diff] [review]
patch

This patch catches the error condition and throws an alert dialog.

Comment 10

16 years ago
Comment on attachment 59250 [details] [diff] [review]
patch

>Index: res/content/filepicker.js
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/filepicker/res/content/filepicker.js,v
>retrieving revision 1.60
>diff -u -r1.60 filepicker.js
>--- filepicker.js	2001/11/15 05:37:32	1.60
>+++ filepicker.js	2001/11/27 00:00:16
>@@ -519,7 +519,17 @@
>   addToHistory(directory.unicodePath);
> 
>   window.setCursor("wait");
>-  outlinerView.setDirectory(directory);
>+  try {
>+    outlinerView.setDirectory(directory);
>+  } catch(ex) {
>+    var errorTitle = gFilePickerBundle.getString("noPermissionTitle");
>+    var errorMsg = gFilePickerBundle.getString("noPermissionError");
>+    promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
>+                              .getService(Components.interfaces.nsIPromptService);

This should have a |var|

>Index: src/nsFileView.cpp
>+    // Couldn't read in the directory, this can happen if the user does not
>+    // have permission to list it.

Do we know this will only happen when the user doesn't have permission to read
the directory? What about cd'ing into it?

>Index: res/locale/en-US/filepicker.properties
>+noPermissionTitle=Error opening directory
>+noPermissionError=You do not have the permissions necessary to view this directory.

If there are other cases where setDirectory might fail, this message should
have a
qualifier like "most likely".
(Assignee)

Comment 11

16 years ago
Fixed the |var|.  I suppose this could also happen if there was some filesystem
error, but since we have already checked to be sure that the directory exists, I
can't think of any other reason that the user couldn't list it besides a
permissions problem.  For our purposes, the distinction between listing the
directory and cd'ing into it isn't really important.

Comment 12

16 years ago
r=jag then
Comment on attachment 59250 [details] [diff] [review]
patch

Well, a directory removal could race with us, but I don't care.

sr=shaver, also marking r for jag.
Attachment #59250 - Flags: superreview+
Attachment #59250 - Flags: review+
(Assignee)

Comment 14

16 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
vrfy fixed using 2001.11.28.08-comm linux bits on rh7.2. tested the file picker
via both File Open and File Save. when attempting to go to a dir w/o appropriate
privs, i now get a dialog saying "You don't have the permissions necessary to
view this directory."
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.