Handling Paperclip folder and file permissions using Ruby on Rails

Question

I am running Ruby on Rails 3.0.9 in production mode on a remote VPS machine running Ubuntu 10.04 LTS (in development mode I use RoR on a MAC OS Snow Leopard) and I would like to know how to manage the following scenario.

I use Apache2 and Phusion Passenger and I have set Virtual Host as-like this:

<VirtualHost *:80>
  ServerName project_name.com
  DocumentRoot /srv/www/project_name.com/public

  <Directory /srv/www/project_name.com/public>
    AllowOverride all
    Options -MultiViews
  </Directory>
</VirtualHost>

More, I use the Paperclip gem and, as a lot of people on the web using it in production mode, I get the following error on handling (image) files:

Errno::EACCES (Permission denied - /srv/www/project_name.com/public/images/001):
...

I heard that a solution in order to avoid those kind of errors is to set properly folder permissions (manually! - I don't know if it is possible to automate that "setting" process... BTW: is it possible?) but I think there is a better way to solve that. If so, what can\should I do?

Answer 1

@M. Cypher is close, although the biggest issue I see is that you're allowing users to upload arbitrary files and then marking them all executable. This is a disaster looking for a place to happen.

find /srv/www/project_name.com/public -type d -exec chmod 755 {}\;
find /srv/www/project_name.com/public -type f -exec chmod 644 {}\;

This will set executable on directories (necessary) but not on files.

Answer 2

Why automate it, it just requires a simple command on the server.

sudo chmod -R 777 /srv/www/project_name.com/public

Edit: I have all my Paperclip images in a shared directory, e.g. /srv/www/project/shared/... That way, they are not affected when I deploy a new version with Capistrano and I only have to set the folder permissions once (with the above command or similar). That's why I think automation is not necessary, since you need to run the command exactly once, not after every deploy.

Btw, chmod -R 777 may not be the best choice since it indiscriminately sets every file in every subfolder to be accessible by everyone. It does work, but I'm sure someone with more Linux skills can point out why a less extreme version would be smarter.