Files created by FastCGI server are world-writable

Patch for properly setting umask

I am not an expert on Unix daemons, so I made some research. I found out that setting the umask when daemonizing appears to be standard practice. However, there is some confusion concerning what you actually set it to. The Linux daemon-writing howto (http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html) says to set it to zero, with the following rationale:

"By setting the umask to 0, we will have full access to the files generated by the daemon. Even if you aren't planning on using any files, it is a good idea to set the umask here anyway, just in case you will be accessing files on the filesystem."

This doesn't make much sense to me. Other texts, such as the howto daemonize, http://www-theorie.physik.unizh.ch/~dpotter/howto/daemonize, also recommend to set the umask to 0, without rationale. Finally, other texts recommend a nonzero value for the umask. For example, the Unix Daemon Server Programming, http://www.enderunix.org/docs/eng/daemon.php, says:

"Most servers runs as super-user, for security reasons they should protect files that they create. Setting user mask will prevent unsecure file priviliges that may occur on file creation."

and it gives, as an example, a umask of 027.

My conclusion is that it is good practice, when daemonizing, to properly reset the umask to a sane value; otherwise you inherit the parent's umask, and this might be insecure. But the actual value to which you set the umask to should be sane, and definitely nonzero. I don't know why some people recommend setting it to zero, but I dare wildly guess that an error was once made in some howto and then it has been copied generously. I can't find any other explanation.

Since there is no single umask value that can fit all cases (for example, I think 027 is reasonable, but in my installation I happen to need 002), it must be possible to override. I therefore wrote a patch where you can specify the umask as a runfcgi option, and the default is a sane 027.

Updated patch, default umask now 022 instead of 027

I think that using a umask of 027 may break backwards compatibility and create unexpected results. Specifically, uploaded files would now be unreadable by "other", which usually includes the web server, which means that in some installations newly uploaded files might be unreadable until the umask is set. So I changed the default umask to 022 and uploaded an updated patch.

Hi Simon,

when you check "needs documentation", is this something for me? I _have_ provided documentation (albeit only one line), the topmost modification in the patch. Is more than that needed?

Replying to aptiko:

when you check "needs documentation", is this something for me? I _have_ provided documentation (albeit only one line), the topmost modification in the patch. Is more than that needed?

Errr... documentation does not mean comments, the contributing doc says it all, patches should have (when applicable):

• The patch itself (code changes).
• Tests that reproduce the bug fixed (and hence, pass) or that test the new functionality
• Documentation, changes to the docs/ folder so users see those changes.

Replying to telenieko:

Errr... documentation does not mean comments, the contributing doc says it all, patches should have (when applicable): * Documentation, changes to the docs/ folder so users see those changes.

The docs/ directory does not document any of runfcgi's arguments: there is nothing about workdir, outlog or errlog in there. The only thing that is mentioned is (http://www.djangoproject.com/documentation/fastcgi/):

"If you specify help as the only option after runfcgi, it’ll display a list of all the available options."

The modifications I've provided include documentation of "umask" in "runfcgi help". If a one-liner there is enough for the "workdir" parameter (and in my opinion it is), then a one-liner about "umask" should also suffice.

Good catch. I'm a bit embarrassed to have missed this when the initial idea was floated. 022 is a pretty normal umask value in these situations, so it's a good default. Thanks for the patch.

(In [7800]) Fixed #6994 -- For fastcgi, set a more sensible default umask. Also allow the umask value to be customised. Thanks, Antonis Christofides.