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

Status: NEW

(Firefox :: File Handling, defect)

Description

[Jeremy M. Dolan]

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.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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).

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Oops I read this wrong.  It doesn't seem so outlandish now looking at it the
right way.

Comment 4

[Bill Law]

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?

Comment 5

[Vedran Miletic]

retargeting

Comment 6

[Graham Reed]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

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

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

Comment 9

[Craig Ringer]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[zug_treno]

(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).

Comment 12

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 13

[Sascha Nemecek]

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

[zug_treno]

(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

[Sascha Nemecek]

Yes, indeed! Thanks for the hint.

Comment 16

[Sebastian Freundt]

Still broken in 29.0a1.

Comment 19

[a3nm]

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

[a3nm]

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

[Cœur Noir]

Firefox 45 still does not follow system umask.

Comment 24

[Magnus Melin [:mkmelin]]

Attachment: bug120679_mc_fix_umask.patch

Reasonably not going to have time to finsih this. Found an very old patch if someone's ever interested.

Comment 25

[gabriel]

Firefox 115 is not following the download directories default acls (which supposed to superseed umask when found). This is in particular an issue when running firefox as a different user as the session and trying to share downloads via acls.