Considering that various other parts of Rails recommend 0666 perms on log
files, I'd say it was definitely deliberate. Ill-advised, definitely, but
deliberate.
My guess would be to support FCGI processes that are running the same use as Apache which would usually be a different user and group from the user uploading and deploying the application files.
Considering that various other parts of Rails recommend 0666 perms on
log
files, I'd say it was definitely deliberate. Ill-advised, definitely,
but deliberate.
Hmm, but why would rails ever recommend something that is ill-advised?
My guess would be to support FCGI processes that are running the same use as
Apache which would usually be a different user and group from the user
uploading and deploying the application files.
Solved on all my servers with:
chgrp -R www-data log tmp
chmod -R g+w log tmp
- Matt
Actually, after digging into this a bit more, it's not really Rails' fault. The rails command does create a production.log, but most people don't actually check that in to their repository or deploy it. Rather, the Ruby Logger class creates the file on the fly when the app is started. This is creating the file as 0666.
I would still like to figure out some way to configure Logger to do 0660 rather than have to rely on chmod-ing after the fact. But, that's clearly something I should take up with the Ruby folks.
Your issue is solved, but nevertheless I would like to chime in.
AFAIK Rails consciously avoids being paranoid about most of the permissions (also having a user in the db that can modify
tables). In the long run being too paranoid causes more grief than convenience. If you need stuff to be locked tight modify your deployment scripts accordingly
Or you can indeed make your own Logger (which seems the easiest to me).