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.
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
16 years ago
Depends on: 124307
Target Milestone: mozilla1.1alpha → Future
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
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.
(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.
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
I'm currently experiencing this problem on Ubuntu 9.10 with TB3 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11pre) 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?
(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.
Yes, indeed! Thanks for the hint.
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)
Still broken in 29.0a1.
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).
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!
Firefox 45 still does not follow system umask.
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.