File saving on UNIX should pass mode 0666 for files, 0777 for directories (which makes the system umask apply)

NEW
Assigned to

Status

()

Firefox
File Handling
17 years ago
5 months ago

People

(Reporter: Jeremy M. Dolan, Assigned: Magnus Melin)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
We are currently pretending we know better then the user, system, and system
administrators by passing modes such as "0644" and "0755" to nsILocalFile. The
only times 0666 and 0777 SHOULDN'T be used is for temp file creation, and
profile directory creation. This is standard practice.
Um, what?  Standard practice?  By whom?  I don't want *anything* on my system to
be 0777.  If I did, I'd use Windows 9x or something.

File an RFE for a pref to let you set what you want your default to be or for us
to read the users' umask (do we do that currently?)

But don't blindly set 0777/0666 ever.  I strongly advise wontfix'ing this.  If a
sysadmin wants to escalate permissions on files in their system, then they
should know how to do it.  But do not force users to lower permissions.
Christopher, the point is that when the user's umask is taken into account (libc
handles this) the resulting permissions will not be 777 or 666.  But the power
is in the hands of the user to make the permissions whatever the user wishes.

Are we sure that nsLocalFileUnix is the only platform-specific impl that uses
the mode values?  Are we sure that all things that use nsLocalFileUnix do
umasks?  (eg VMS/BeOS/QNX; not sure which localfile impl OS/2 uses).
Oops I read this wrong.  It doesn't seem so outlandish now looking at it the
right way.

Comment 4

17 years ago
Setting milestone to off in future.

I coded up the fix for a specific instance of this.  Can we do that, rather 
than leave one big open-ended bug?
Target Milestone: --- → mozilla1.1
QA Contact: sairuh → petersen

Comment 5

15 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future

Comment 6

15 years ago
I have issues with using 0600 for temp file creation as well.  If the files are
for security keys or things like that, sure, 0600 is more than appropriate.

But what about the temporary files created during download?  There is nothing I
find more frustrating than Mozilla's insistance in making all files 0600 during
download.  Part of my JOB is downloading stuff from the 'net, building it, and
putting it up on a central server.  And every now and then, something which
doesn't need compilation (such as an install .exe file for Windows) needs to be
downloaded and gets put on the server so that no-one else can read it.

It's annoying.  My umask is set the way I want it set, for a reason.  If I'm
downloading stuff at work that I don't want others to read, well, actually I'll
SSH to my home machine and use links or wget instead.

(And shouldn't this be Hardware: All and OS: POSIX?)

If I was the kind of guy to just modify the source to do what I want, I might
change the 0600s in uriloader/exthandler/nsExternalHelperAppService.cpp to 0666
and build my own copy.
The point is that the stuff you're downloading may be sensitive (eg PDFs that
include personal info in many fellowship application web sites) and it's stored
in /tmp, which is world-readable.  The user may not even realized it's stored in
a world-readable location, and hence may not expect that they'll need a umask
set accordingly.

And it's nice that this is not a problem for you "at work", but some people use
shared systems where this IS a problem.
after bug 69938 is fixed, we can probably pass 0666 and let umask do it's thing,
because we will save directly into the target dir
Depends on: 69938

Comment 9

13 years ago
This is also a serious problem on shared systems as well.

The users here have a umask of 002. They work in groups, and need to have directories created by Thunderbird or Mozilla Mail (and files saved by it) to be group writeable. As thunderbird creates directories without group write permission, this causes endless strife. I've had to hack around it with a horrific cron job.

If your concern is permissions when saving in /tmp, then save files with more secure permissions in /tmp . Otherwise, the user's umask should be respected.
This bug is about saving files.  That's it.  If there is a problem with the way Thunderbird creates directories, please file a separate bug on thunderbird.

Comment 11

13 years ago
(In reply to comment #10)
> This bug is about saving files.  That's it.

I'm not sure, Firefox bug 325334 is about saving directories so is it still a duplicate of this bug? (Bug 325334 comment 3 mentions a workaround for saving directories as 775).
> Firefox bug 325334 is about saving directories

That's fine, as long as we're talking about the "save as" codepaths from browser.  Mailnews (comment 9) uses something totally different, however.

Bug 325334 is not quite a dup because I think it needs more work than this bug.  But it's dependent.
Blocks: 325334

Updated

9 years ago
Assignee: law → nobody
QA Contact: chrispetersen → file-handling

Comment 13

8 years ago
I'm currently experiencing this problem on Ubuntu 9.10 with TB3 

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b2pre Shredder/3.0.3pre 


When saving files or creating directories, the umask is ignored and my colleagues cannot access the files. IIRC this problem didn't exist with TB2. Is there any fix yet?

Comment 14

8 years ago
(In reply to comment #13)
> When saving files or creating directories, the umask is ignored and my
> colleagues cannot access the files. IIRC this problem didn't exist with TB2.

This might be MailNews Core bug 533976.

Comment 15

8 years ago
Yes, indeed! Thanks for the hint.
(Assignee)

Updated

5 years ago
Assignee: nobody → mkmelin+mozilla
Summary: File saving on UNIX should pass mode 0666 for files, 0777 for directories → File saving on UNIX should pass mode 0666 for files, 0777 for directories (which makes the system umask apply)

Comment 16

5 years ago
Still broken in 29.0a1.

Updated

4 years ago
Duplicate of this bug: 959540

Updated

4 years ago
Duplicate of this bug: 1009718

Comment 19

3 years ago
Still seems to occur on iceweasel 41.0. Several profile files (extensions.json, sessionCheckpoints.json, sessionstore.js, etc.) are still created with permissions 600 despite a umask of 002.
That has nothing to do with this bug, which is about saving files from the web, not files in the profile (which might be security-sensitive and hence have restricted permissions on purpose).

Comment 21

3 years ago
Oh, apologies. I was misled by the fact that https://bugzilla.mozilla.org/show_bug.cgi?id=1009718 was marked as a duplicate of this bug. Bug 1009718 is definitely about files in the profile. I'll comment there instead. Sorry!

Comment 22

2 years ago
Firefox 45 still does not follow system umask.

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified

Updated

5 months ago
Duplicate of this bug: 1427394
You need to log in before you can comment on or make changes to this bug.