105809 - mozilla crashes on open file for unpriv users

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Wayne Sewell]

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.

Comment 1

[Matthias Versen [:Matti]]

-> File Handling

Comment 2

[Matthias Versen [:Matti]]

.

Comment 3

[Colin Blake]

Since this is OpenVMS, I will debug to find out what's going on. 

Comment 4

[Colin Blake]

Reproduced on M0.9.5. It hangs at [000000] if you don't have privs. Its not 
consuming any CPU though.

Comment 5

[Colin Blake]

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!

Comment 6

[sairuh (rarely reading bugmail)]

bryner?

Comment 7

[Brian Ryner (not reading)]

We now _crash_ in this situation... 

Comment 8

[sairuh (rarely reading bugmail)]

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) 

Comment 9

[Brian Ryner (not reading)]

Attachment: patch

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

Comment 10

[jag (Peter Annema)]

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".

Comment 11

[Brian Ryner (not reading)]

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

[jag (Peter Annema)]

r=jag then

Comment 13

[Mike Shaver (:shaver emeritus)]

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.

Comment 14

[Brian Ryner (not reading)]

checked in

Comment 15

[sairuh (rarely reading bugmail)]

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."