Closed Bug 624995 Opened 13 years ago Closed 13 years ago

Does not set filesystem permissions correctly for saved files


(Core Graveyard :: File Handling, defect, P1)



(blocking2.0 betaN+)

Tracking Status
blocking2.0 --- betaN+


(Reporter: hamster163, Assigned: bzbarsky)



(Keywords: regression, Whiteboard: [softblocker])


(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

For every file saved from Firefox, the file is given the permission of "rw-------" (i.e. "600"). This makes the file not readable by other users, both locally and/or after being copied to another UNIX-like machine. The desired behavior is "rw-r--r--" (i.e. "644").

Reproducible: Always

Steps to Reproduce:
1. Save any file from Firefox
2. Check the file's permission by typing "ls -l <file_name>" in the Terminal window

Actual Results:  
The file has the permission of "rw-------".

Expected Results:  
The file should have the permission of "rw-r--r--".
what are the folder permissions of that folder where you save the file ?
The folder permission is "rwxr-xr-x" (the default). I switched back to Firefox 3.x and the problem disappeared without any further tuning => something is not right for 4.0 beta.
Component: General → File Handling
Keywords: qawanted
Product: Firefox → Core
QA Contact: general → file-handling
I'm not sure why this ever worked for you.  Temp files during download are created using 0600 for the permissions, because they often live in a world-readable directory, so making them world-readable would be a privacy hole.  This has been the case going back to Firefox 3.0.

When the download is done, the file is moved from the temp location to the final location.  This doesn't change the permissions, of course.
That said, I do see the behavior change from 3.6 to 4.0.  Interesting....
The behavior changed back in July in this range:

That's when we stopped using a custom file object implementation for OSX and started just using the generic Unix one.

The old implementation was just buggy (in an insecure way, in this case): it ignored the permissions mask passed to the Create() call.

I'm pretty sure we have existing bugs about the fact that umask is not applied properly to files in this situation; the problem is that there is no sane way to apply the umask when moving a file.
Blocks: 571193
Keywords: qawanted
Whiteboard: DUPEME
bug 612209 looks like a dupe but I can't find the umask/move case
> bug 612209 looks like a dupe

Yeah, of this bug.  We have much older bugs on Linux for the behavior, iirc.
do you mean bug 124307 ?
Aha!  Yes, indeed.  Looks like we need to do that in the OS X code too.  Thanks!
Assignee: nobody → bzbarsky
Ever confirmed: true
Whiteboard: DUPEME
Sadly, I have no idea how to add a regression test for this.
blocking2.0: --- → ?
Keywords: regression
Whiteboard: [need review]
Priority: -- → P1
blocking2.0: ? → betaN+
Attachment #503542 - Flags: review?(joshmoz) → review+
Whiteboard: [need review] → [need landing]
Whiteboard: [need landing] → [need landing][softblocker]
Closed: 13 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [need landing][softblocker] → [softblocker]
Target Milestone: --- → mozilla2.0b10
Depends on: 635152
No longer depends on: 635152
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.