On Sat, Jun 29, 2013 at 9:56 PM, Juan Luis Boya <ntr...@gmail.com> wrote: > > When daemonize=false, it will set the umask for Django child > processes, effectively changing default permissions for newly created > files, including the socket. When daemonize=true, it will do nothing.
Hrm no. It's exactly the opposite. > > What sense makes that? Is there any case in where I would like my > Django process umask to be different when I run it in the background > than when I run it on the foreground? I can't think of any. Is there > even any logical reason for the default umask for new files setting to > be a runfcgi argument? > > On the other hand, I feel a flagrant miss: I need to set the > permission mask just for my socket, not for other files. I want my web > server being run as a different user and I want it to be able to write > on the socket, but not to overwrite uploaded files, for example. I am > not entirely alone. There are questions like this in StackOverflow > [1], in this list [2], in the IRC logs [3] and I would bet there is > many people suffering it in silence. This is ticket #14958. I think there is value in having the ability to set both the umask of the forked process to control the permission mode of files/dirs created (and so not use the umask of the parent, launching process) as it is already possible and the umask of the Unix socket used to communicate with the FastCGI-speaking web server as proposed, using the facility provided by Flup. FastCGI-related reports are scarce and contributions are almost non-existent which IMHO seems to indicate it isn't a widely used deployment technique. You seem to have experience with it and to have a test setup so if you can fix/update (complete with documentation additions and corrections, a lot of bonus points if you can figure a way to write some tests,-)), and try the associated patch then the ticket can reach a status in which it's ready to be applied. On Sun, Jun 30, 2013 at 12:11 PM, Juan Luis Boya <ntr...@gmail.com> wrote: > They talk about there was a os.umask(0) and they created that option > in order to change it. > >But I would like to know then, why was that `os.umask(0)` there in the >first place? What was it purpose? Seems like some code history research work similar to the one suggested by Karen is in order if you really want to understand the original motivations. > On the other hand there is the confusion this option brings. Many > people think the option is intended to set the socket umask. Just in > that bug report there is a user saying "umask=0111 creates a socket > with umask...". That particular comment is talking about another issue that has been fixed (the pased umask value was interpreted incorrectly.) Regards, -- Ramiro Morales @ramiromorales -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
