Why is it necessary to chmod o+r parent directory to fix 403 access forbidden error with Nginx and Passenger?

Question

This may be an Nginx wrinkle, or it may be because I don't understand Unix permissions.

We're using Hudson CI to deploy our staging instance. So RAILS_ROOT is /var/lib/hudson/jobs/JOBNAME/workspace.

• Hudson runs as hudson user
• Nginx runs as www-data user
• hudson and nginx are both members of the www group
• root of my nginx conf points to RAILS_ROOT/public as per normal.
• RAILS_ROOT/config/environment.rb is owned by www-data (so Passenger runs as www-data)
• RAILS_ROOT and everything in it is owned by the www group and group has r/w/x permissions

As it stood, Nginx threw 403 permission denied when requesting any url. error.log contained entries like this: public/index.html" is forbidden (13: Permission denied).

These did not fix the or change the error (each with a stop/start of Ngnix):

• chmod 777 -R RAILS_ROOT
• chgrp www -R /var/lib/hudson

I also tried Nginx as root, and passenger complained that it could not find config/environment (despite the path displayed on the error page being correct).

The fix was to ensure everybody has read permissions on each directory in the heirachy. In this case chmod o+r /var/lib/hudson.

But if the group has read permissions on the directory, and nginx is a member of the owner group of the directory, why was it necessary to allow everyone read permissions? Is there something have not grokked about permissions?

$nginx -V
nginx version: nginx/0.7.61
built by gcc 4.4.1 (Ubuntu 4.4.1-4ubuntu8) 
configure arguments: --prefix=/opt/nginx --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/ext/nginx --with-http_ssl_module --with-pcre=~/src/pcre-8.00/ --with-http_stub_status_module

$cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

Answer 1

www-data may have shell like /bin/false, so if you want to check exactly where is problem, do following: switch to root(su or sudo -i), then run

# su -s /bin/bash www-data
$ cat /path/to/problem/file

And you will see, is this problem about permissions or somewhere else.

UPD:
Hmm... I din't look at post writing time. Is there "necropost" achievement on serverfault.com? :)

Answer 2

*nix and group permissions can be a bit funny. If a user is a member of multiple groups they may have access to some files while not actually being able to access them! As far as I understand it on the typical *nix system you essentially appear to belong to a single group at a time. Being a member means that you can switch to another group, or programs that check things more thoroughly (like su running on a redhat variant) will be able too see that you are a member of the correct group.

There is an sg command that allows you to switch group like su switches user.

To solve your actual problem I think you could probably change the group in the passwd file so that the group you want is the default. That's assuming it doesn't cause you to not be able to access some other files you need.

I believe there are other ACL solutons for *nix that can be installed which work in a more intuitive way but I don't really know anything about them.

Answer 3

No, it's passenger problem. I'm running rails apps using unicorn with least permission granted to nginx. (entire application directory is not global/group readable/executable - except the root directory 710 and public directory 710 with files inside it 640)