Some people may want to run their rails server as one user, deploy their app as another user, run some rake tasks manually or via cron that also write to the same file system as another user, etc. There are a variety of reasons one may want to do this kind of separation, including security. You'd think this should be easy under Unix with a common group they all share, a sane 002 umask, and a group sticky bit for the shared-write-access areas of the app. But it's not, because atomic_write breaks this scenario.
Here's what atomic_write does currently: 1. It writes a new temp file 2. It checks the permissions and ownership of the old file 3. It moves the new temp file over the old file 4. It changes permissions and ownerships of the new file to match the old one. The problem is that you can only change the ownership of a file if you are root (and nobody runs their rails app as root, right?), or if you're changing it to yourself and it's already owned by yourself (in which case, it's a no-op waste of time). Otherwise you get an "Operation not permitted" error. Therefore, since it's not doing any good anyway, I propose we delete the chown line in atomic_write, to allow multi-user access in the above scenario. We can keep the chmod line as is of course. Here's a code snippet from: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/file/atomic.rb # Overwrite original file with temp file FileUtils.mv(temp_file.path, file_name) # Set correct permissions on new file chown(old_stat.uid, old_stat.gid, file_name) ##### <-- delete this line chmod(old_stat.mode, file_name) I am happy to send a pull request on github if people seem to like this idea. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
