Почему необходимо изменить родительский каталог с помощью chmod или + r, чтобы исправить ошибку запрета доступа 403 с Nginx и Passenger?

Это может быть морщина Nginx, или это может быть потому, что я не понимаю разрешений Unix.

Мы используем Hudson CI для развертывания нашего промежуточного экземпляра. Так RAILS_ROOT является /var/lib/hudson/jobs/JOBNAME/workspace.

Хадсон работает как hudson пользователь
Nginx работает как www-data пользователь
hudson и nginx оба являются членами www группа
root из моего nginx conf указывает на RAILS_ROOT/public как обычно.
RAILS_ROOT/config/environment.rb принадлежит www-data (так что Пассажир работает как www-data)
RAILS_ROOT и все в нем принадлежит www группа и группа имеют разрешения r / w / x

Как он стоял, Nginx бросил 403 permission denied при запросе любого URL. error.log содержали такие записи: public/index.html" is forbidden (13: Permission denied).

Они не исправили и не изменили ошибку (каждая с остановкой / запуском Ngnix):

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

Я также пробовал Nginx как root, и пассажир пожаловался, что не может найти config/environment (несмотря на то, что путь, отображаемый на странице ошибки, правильный).

Исправление заключалось в том, чтобы everybody имеет права на чтение для каждого каталога в иерархии. В таком случае chmod o+r /var/lib/hudson.

Но если группа имеет разрешения на чтение в каталоге, а nginx является членом группы владельцев каталога, почему было необходимо разрешить все читать разрешения? Есть что-то не грокнули по поводу разрешений?

$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"

www-data может иметь оболочку типа /bin/false, поэтому, если вы хотите точно определить, в чем проблема, сделайте следующее: переключитесь на root (su или sudo -i), затем запустите

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

И вы увидите, это проблема с разрешениями или где-то еще.

UPD:
Хм ... Я не смотрю на время написания поста. Есть ли на serverfault.com достижение "некропост"? :)

* nix и групповые разрешения могут быть немного забавными. Если пользователь является членом нескольких групп, он может иметь доступ к некоторым файлам, но не может получить к ним доступ! Насколько я понимаю, в типичной системе * nix вы, по сути, принадлежите к одной группе за раз. Членство означает, что вы можете переключиться в другую группу, иначе программы, которые проверяют вещи более тщательно (например, su, работающий в варианте redhat), тоже смогут увидеть, что вы являетесь членом правильной группы.

Существует команда sg, которая позволяет переключать группу, как su переключает пользователя.

Чтобы решить вашу актуальную проблему, я думаю, вы могли бы изменить группу в файле passwd, чтобы группа, которую вы хотите, была по умолчанию. Предполагается, что это не означает, что вы не сможете получить доступ к некоторым другим нужным файлам.

Я считаю, что есть другие решения ACL для * nix, которые можно установить, которые работают более интуитивно, но я действительно ничего о них не знаю.

Нет, это проблема пассажира. Я запускаю приложения rails с использованием единорога с наименьшим разрешением, предоставленным nginx. (весь каталог приложения не является глобальным / групповым, читаемым / исполняемым, за исключением корневого каталога 710 и общего каталога 710 с файлами внутри него 640)