Does not set filesystem permissions correctly for saved files

RESOLVED FIXED in mozilla2.0b10

Status

defect
P1
normal
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: hamster163, Assigned: bzbarsky)

Tracking

({regression})

Trunk
mozilla2.0b10
x86
macOS
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [softblocker])

Attachments

(1 attachment)

Reporter

Description

9 years ago
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 ?
Reporter

Comment 2

9 years ago
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: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ac07fe5f6c9&tochange=0f5fc40c6a0f

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
Duplicate of this bug: 612209
> 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
Status: UNCONFIRMED → NEW
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

Updated

9 years ago
blocking2.0: ? → betaN+

Updated

9 years ago
Attachment #503542 - Flags: review?(joshmoz) → review+
Whiteboard: [need review] → [need landing]

Updated

9 years ago
Whiteboard: [need landing] → [need landing][softblocker]
Pushed http://hg.mozilla.org/mozilla-central/rev/7cab48d6f673
Status: NEW → RESOLVED
Closed: 9 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.