Open Bug 298528 Opened 19 years ago Updated 2 years ago

Mozilla should convert from PR_Open() --> PR_OpenFile()

Categories

(Firefox :: File Handling, defect)

x86
Windows XP
defect

Tracking

()

People

(Reporter: dougt, Unassigned)

Details

On windows the mode flag ignored.  this may be a problem on multi user machines.
 Just about zero of our code uses PR_OpenFile.
Summary: PR_Open() --> PR_OpenFile() → Mozilla should convert from PR_Open() --> PR_OpenFile()
PR_OpenFile and the related function PR_MakeDir
implement the Unix/POSIX file permissions on
Windows.  They work well when the file and its
parent directory are both created by PR_OpenFile
and PR_MakeDir.  However, there may be undesirable
interactions when the file is created by PR_OpenFile
but its parent directory is not created by PR_MakeDir.
We ran into such a problem before. I seem to remember
the problem was that we could not delete a file
created by PR_OpenFile because its parent directory
(not created by PR_MakeDir) had the wrong permissions
or didn't have the right permissions.

So you need to think about the "delete" permission
and you need to think about the permissions of the
parent directory whenever you use PR_OpenFile.
What kind of impact does the use of PR_Open() have on security?  Does this need
to block Firefox 1.5?
Setting blocking request flag so that maybe we can get an answer to comment 2...

Frankly, I think this bug should have been filed as not sensitive -- it would be a lot more likely to be fixed by now.
Flags: blocking1.8rc1?
Flags: blocking1.8rc1? → blocking1.8rc2?
This bug should not be security-sensitive.  Doug, please
remove the security-sensitive flag if you agree.

This bug should not block mozilla1.8rc2 because there is
no patch.
On a multi-user windows box, if I create a file with 0700, can another user read|write|execute this file?  If so, I think this might be a security sensitive bug.
per an IM conversation with Doug, it's unlikely we'd respin the release for this. Could be a good candidate to get on the nomination radar for the next release though. 
Even if it is a security issue - it is a local problem only - not XSS or remote code exploit - so we'd likely not respin for this.  Given that and the lack of patch minusing for now.  
Flags: blocking1.8rc2? → blocking1.8rc2-
Group: security
mass reassigning to nobody.
Assignee: dougt → nobody
QA Contact: ian → file-handling
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.