Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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"
share|improve this question
add comment

3 Answers

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? :)

share|improve this answer
add comment

*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.

share|improve this answer
    
That is not quite like that. A process runs with a single 'gid' (let's ignore effective/real/saved gid differences) but also may be a member or multiple groups. The usual problems are: - only the process gid affects the ownership of files created, though the gid and the groups define what files may be accessed - when switching 'personas' the gid and the groups are set with different system calls. Many processes only set the gid when switching from root to the target uid and the groups from /etc/group are ignored for these processes. –  Jacek Konieczny Feb 28 '10 at 10:18
    
Wrong. Unixes know how secondary groups work with permissions. You dont have to sg to get access to files readable only to your secondary groups. –  bot403 Nov 17 '10 at 21:06
add comment

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)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.