Closed Bug 105809 Opened 23 years ago Closed 23 years ago

mozilla crashes on open file for unpriv users

Categories

(Core Graveyard :: File Handling, defect)

All
Linux
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: wayne.sewell, Assigned: bryner)

Details

(Keywords: crash)

Attachments

(1 file)

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.
Severity: normal → critical
Keywords: hang
-> File Handling
Component: Browser-General → File Handling
.
Assignee: asa → law
QA Contact: doronr → sairuh
Since this is OpenVMS, I will debug to find out what's going on. 
Assignee: law → colin
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
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
We now _crash_ in this situation... 
Keywords: hangcrash
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) 
Attached patch patchSplinter Review
This patch catches the error condition and throws an alert dialog.
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".
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.
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+
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 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.

Attachment

General

Created:
Updated:
Size: