Здравствуйте (Hello).
Это самая обычная проблема shared-хостинга.
Я решил ее с помощью ACL (access-control lists).
drwxrwx---* 2 /home 1024 дата root wheel
drwxr-x---* 2 /home/user1 512 дата usr1 usr1
drwxr-x---* 2 /home/user2 512 дата usr2 usr2
...
getfacl /home
#file:home
#owner:0
#group:0
user::rwx
user:www:--x
group::rwx
mask::rwx
other::---
getfacl /home/user1
#file:user1
#owner:1001
#group:1001
user::rwx
user:www:r-x
group::r-x
mask::rwx
other::---
PHP/FastCGI выполняется отдельным процессом от каждого юзера с
помощью spawnfcgi из пакета lighthttpd.
nginx выполняется от юзера www, и таким образом имеет права на чтение
статики, но не имеет даже прав на чтение списка директорий в /home -
уж на совсем страшный случай.
Про то как начать использовать ACL я узнал на и
вам рекомендую, хотя, конечно, источники у всех свои.
P.S.: Кроме этого решения есть еще патч ядра, вы можете разрешить
юзеру nginx иметь доступ там, где нет chmod o+rx. Поводы не
пользоваться этим способом для меня очевидны.
P.P.S.: Ваши вопросы не совсем касаются специфики именно nginx,
поэтому вы, наверное, попали в ту же ситуацию, что и я год назад,
когда пришлось вдруг изучать администрирование сервера на FreeBSD и
настройку shared hosting. Поэтому какие-то общие схемы я бы
посоветовал искать на том же OpenNET, а конкретные детали готов
обсудить в аське 145-542-767.
--
С уважением (Best regards),
Шепелев Сергей Александрович
(Sergey A. Shepelev).
--
История переписки (conversation history):
>>> И всетаки пока непонятно, как решить эту проблему...
>>> Без установки на скрипт прав 644...
>>>
>> Добавить пользователя www-data в группу wwwsite.
>>
> Тогда теоретически пользователь wwwsite1 сможет читать искодный код
> скриптов пользователя wwwsite2. (При наличии уязвимостей в nginx, php)
