263816 - Moz. under Windows fails to properly handle file permissions

Status: RESOLVED INVALID

(Core :: Widget: Win32, defect)

Description

[Joe Schottman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910

Under Windows, Mozilla fails to handle situations where the user does not have
read permission properly.

Example 1: If the user attempts to open a file that they lack permission to read
from Explorer, Mozilla will open a blank page without giving a warning that the
user does not have permission to open the file.
Example 2: If the user attempts to upload a file via an HTML submit form that
they do not have permission to read, Mozilla will upload a 0K file with the
selected file name.  This will cause some cgi programs that process the form
data to stop functioning properly.

With both examples, Mozilla under Linux will display an error stating that the
user does not have permission to access the file.

This has been verified under XP as well as W2K.

Reproducible: Always
Steps to Reproduce:
Example 1:

1. Take any example file on a Windows system and remove read access for your
user account.
2. Open the file in Mozilla from Explorer.

Example 2:

1. Take any example file on a Windows system and remove read access for your
user account.
2. Go to any website that has a form based file upload.  (webmail, file storage,
etc.)
3. Attempt to upload the file.

Actual Results:  
Example 1: Opens a blank Mozilla page with no data.
Example 2: Uploads a 0K sized file.

Expected Results:  
Example 1 and 2: Display an error message indicating that the user does not have
read access to the file.

Comment 1

[Aaron Lawrence]

Confirming both those problems. Couldn't find any obvious dupes.
To add to part 1, if you already have a window open on a URL, and try to Open
File... and pick your inaccessible file, Mozilla does nothing at all; doesn't
display an error, or the file: URL, or anything.

Part 2 is nasty as you can select the file (assuming the directory is
accessible) and everything appears to work (the server gets successful result
codes), but it doesn't.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Aaron, confirming a bug in browser-general is a good way to ensure no one ever
sees it.

Confirming a bug that should be two separate bug reports is not so cool either...

The second issue reported is a problem of the filepicker implementation.  I have
no idea where the first problem reported should be (networking?).

Reassigning to GFX for the second problem, but we need a separate bug report on
t the first one.

Comment 3

[Joe Schottman]

(In reply to comment #2)
OK, I know that I'm new to the whole Bugzilla process, but what on earth are you
talking about?

There is a single conceptual bug here, which is that Moz. for Windows fails to
handle being denied read (and write! - see below) permission to a file.  This
may be implimented in various ways in different parts of the code, but they
should be grouped together so that someone who sees one part of the problem
might recognise where else it might occur in the code.

Why would the first example be filed under networking?  It has nothing to do
with the network.  It is a problem with local files and the browser.

And unless the GFX: Win32 is your catchall for anything related to Windows only
problems, this has nothing to do with "Cross platform rendering interfaces and
cross platform base implementations. Bugs that belong in this component are
cross-platform problems with painting, such as fonts getting cropped or
underlines not getting correctly removed with dynamic effects..."

So, going back to the problem, I've discovered another facet of this bug, which
is that it also fails to handle write permission denial.  Such that if I'm
working on a file that I have read permission for but not write permission and
save it, Moz. will happily act as if it has been saved, when if fact it hasn't.
 I view this as a fairly sever bug (potential dataloss on the part of the user),
but will leave it up to someone else to kick it up in priority.

I've located what may be part of the code is going wrong with the filepicker aspect:

/$MOZSOURCEDIR/xpfe/components/filepicker/res/content/ has a file filepicker.js
that handles error reporting for files.  Specifically lines 280-304, which deal
with opening and saving files.

/$MOZSOURCEDIR/js/src/ has js.c which deals with opening files

But I'm new to Mozilla code, so the problem could be someplace else.  Could
someone confirm this and change the component to Javascript if that is the case?

P.S. Problem is verified to exist with Moz. 1.8a5 Gecko/20041016

Comment 4

[Aaron Lawrence]

File Handling makes more sense.
Boris: noted. I'll stop trying to help.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Joe: yes... the code involved is very likely different in the three cases you
cite, and may well be fixed by different people. in order to more easily track
these problems, there should be one bug per problem, which can be individually
tested, fixed and verified.

/$MOZSOURCEDIR/xpfe/components/filepicker/res/content/ is not used on windows,
where a native file picker is used (widget/src/windows/nsFilePicker.cpp has the
code)

since this is widget code, and we don't have an own component for that, using
gfx for it doesn't sound like too bad an idea.

/$MOZSOURCEDIR/js/src/'s file reading code is not used in mozilla

mozilla's networking code is also used to access local files, hence bz's
suggestion of a networking bug.

> it also fails to handle write permission denial

in which case? mozilla is writing to files in a lot of places... since I hope
the code that actually does the writing handles this correctly, this is probably
the caller's fault, which can be anywhere in the tree...

bz:
> The second issue reported is a problem of the filepicker implementation.

I would claim it's (also) a bug in the form submission code, which ignores the
error from file opening (presumably NewLocalFileInputStream returned an error).
it even accepts nonexisting files! (cross-platform)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Aaron, the point was that you should reassign bugs out of browser-general when
you confirm them.  If you can't figure out the right component, ask on IRC. 
People are very willing to help with that.

Joe, sending empty for unreadable files if the user actually manages to select
them is expected browser behavior.  Last I checked, that's what IE did if you
typed in a filename directly into the file upload control.  Am I wrong?

As for the rest, networking in Mozilla handles all interaction between the
layout engine and the outside world, INCLUDING local file access.  The local
file case sounds like networking is not returning the right errors to the layout
code.  Finally, biesi is right -- it's the responsibility of callers of file i/o
operations to check for success, so the saving issue you're reporting is yet a
third bug.

Comment 7

[Brian R. Bondy [:bbondy]]

OK I spent a couple hours reading through all of this and reproducing, and I filed 3 bugs that follow the discussions and give exact steps to reproduce each.  Each are in a different component (networking, win32 widget, and toolkit/download manager).

1. Bug 682294 - Opening a page which we can't read should display an error page
2. Bug 682293 - File picker allows selection of unreadable files on Windows XP
3. Bug 682292 - Download manager reports success for files that can't be written to

Joe Schottman and Aaron Lawrence: Thanks for the reports.
Boris and Christian: Thanks for the insight on the locations of the problems.