Permissions on downloaded files ignores umask



Download & File Handling
16 years ago
13 years ago


(Reporter: adam shostack, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)




16 years ago
When I download files, the permissions are set to 600.  My umask is set to 27,
so others in my group can read new files.  Mozilla ignores this, and I'm unable
to find a config option to make it respect umask.

Comment 1

16 years ago
that's true. it doesn't respect umask at all.

Comment 2

16 years ago
This is worksforme (20020421 Linux). Did you set the umask and then launch
mozilla from that shell? Reporter (adam shostack), please can you clearly state
what steps you took to produce this bug (e.g. what was downloaded where to and
how you checked) and follow the guidelines at

Could you also check to see whether this bug is still present in a recent build
(Moz1-RC1 or a new nightly build). If this bug does not occur please can you
resolve it worksforme.

Comment 3

16 years ago
It turns out that umask was getting inherited from something in gnome that was
setting it which I've yet to track down.  Mozilla launched from the command line
works as expected.  I've resolved to worksforme, per your request.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 4

16 years ago
Thanks. Verifying..

Comment 5

16 years ago
Reopening since I'm using trunk 2002050821 build under KDE 2.2.2 and Mozilla
definitely ignores my umask.

But it happens only when saving downloaded files to disk (and only then, saving
web pages etc. honours my umask).

In addition, a file has to be downloaded by left-clicking on a link to it, then
choosing "Save this file to disk". If I right-click and choose "Save Link Target
As...", then umask is honoured.

My steps to reproduce this:

1. Launching an xterm window
2. Check your umask (mine is 002)
3. From the xterm window launch Mozilla (e.g. type /usr/local/mozilla/mozilla)
4. Open a page with a file to download (e.g.
5. Click on the link to that file, select "Save this file to disk...", save in a
directory on your disk
6. Check file's permissions. In my case, it's 600 despite the fact that my umask
is 002.
7. Delete that file
8. Right-click on tha link and select "Save Link Target As...", save in the same
9. Check file's permissions. I had 660 (so this time it's in accordance with umask).

Resolution: WORKSFORME → ---

Comment 6

16 years ago
Hmm, well I don't claim to be a umask pro but I don't think the problem is with
umask but rather with the mode...

The umask is used to turn *off* certain bits so if a file was creatd with the
mode 600 then a umask of 002 is going to produce a file with the permissions 600...

However as Aleksander has pointed out that using the right mouse button save
target link as produces a file with the correct permissions to left clicked
saved file so I assume that two different modes are being used when it would
make more sense to use 666 in both cases (this would produce the reporter's
expected behaviour). Confirming (20020426 Linux).

If you are trying to reproduce this then don't forget to delete the file between
Ever confirmed: true

Comment 7

16 years ago
Ben, I'm cc-ing you because this might be your component. wrote:
> Hmm, well I don't claim to be a umask pro but I don't think the problem is with
> umask but rather with the mode...

That's my point. When an application creates a file with mode set explicitly to
600 (instead of 666), it indicates that programmer ignores the existence of
umask facility on Unix systems.

That practice is clearly wrong in my opinion, because it's like trying to access
video hardware directly instead of dependinng on system libraries/gui toolkit
when creating a simple gui app. It's the do-it-all-yourself thinking that
usually spawns from experience in Assembler programming on MS-DOS :-).

My message to those programming on Unix/Linux:
Don't be afraid to rely on umask.
It's always set properly to at least 002 (or 022), unless a user reconfigured
the system. I've never seen a UNIX-like system where umask would default to 000.

See the discussion in this bug:

Comment 8

16 years ago
*** Bug 150586 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 124307 ***
Last Resolved: 16 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 10

15 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.