Из частной переписки:

Мы бы предложили пункт "Нет" расширить до
а) Нет, договором
б) Нет, технически

Да пусть пользователи ставят, что хотят.
Главное - процессы apache запускаются от имени пользователя, а о своих данных пользователь заботится сам...

у, как все запущено. нет конечно, не разрешим когда апач запускается НЕ от имени пользователя (а таких хостинговых платформ большинство).
Самое смешное что там где апач запускается от имени пользователя я бы лично тоже не разрешил - ну зачем развращать пользователей? Сегодня он на папку поставит права 77, завтра пустой пароль на акк. 777 права на любом никсовом сервере где есть больше одного клиента - нонсенс и благодатная почва для всякого рода ломакеров...
777 права нужны был только в одном случае - когда скрипты запускаются от имени юзера nobody (злополучный и ущербный конфиг на базе mod_php запущенный командой разработчиков php которым глубоко плевать на трудности шаред хостинга и на его безопасность) и только потмоу что в таком режиме скрипты создают файлы от того же юзера нободи и потом пользователь ничего с ними сделать не может.

Не разрешаем. Ставят 755 и никаких проблем. SuPHP. Впрочем об этом уведомлено на сайте в заметке "Начало работы", об этом твердиться в службе поддержке, клиенты понимают, проблем не возникает.

К сожалению, многие разработчики на сайтах в документации просят ставить права не так, чтобы писалось, а 777. Именно из-за этого происходит огромная куча проблем.
Насколько я заметил, многие разработчики либо разрабатывают на mod_php, либо под mod_php.

Это говори об ограниченности разработчиков на php, которых многие из-за этого называют "быдлокодеры". Ничего личного.

Вот грамотные разработчики в своем скрипте напишут просто проверку - сделают touch file в каталоге для записи
И если получат ошибку, то сообщат - недостаточно прав для записи файла. Просто и доступно обычному человеку.

С одной стороны полностью согласен с предыдущими ораторами по поводу "не стоит дразнить"... но...
У меня есть два вопроса по этому поводу к участникам:
1. [только в обморок не падайте] а как запретить ставить права 777 ? Вы все ядро что ли для этого патчите или я чего-то не знаю?
2. А есть хоть одна не философская причина вообще следить за правами внутри пользовательских данных? (в рамках виртуального хостинга, конечно)

У нас на одном из серверов suphp, поэтому права 777 запрещены. Проблемы возникали только после перехода на suphp (примерно месяц пользователи привыкали). Сейчас же таких проблем нет, все довольны. Правда некоторые скрипты приходится немного переписывать, т.к. (с)

На другом сервере mod_php. О переходе на suphp пока думаем.

http://ru.php.net/manual/ru/function.is-writable.php

Формально, дело не в кодерах, а в тех, кто пишет мануалы.

Так, стоп... а какие проблемы в 777 на уровне файлов пользователя? _тем более_ если это suphp?

Тем, что если права выше 755, не работают скрипты, выдают 500, и в логах "Premature end of script headers"

У нас нет ни каких проблем вообще, на корневой папке юзера стоят руут права и права 700 а вот всё что внтури делает юзер в общедоступных ему папках абсолютно пофигу хоть 777 хоть 77777777777, и пофигу потому что на вышестоящей папке стоит 700 и юзер сменить их не может и никакие "ломакеры" ничего не сделают из соседних аканутов. И при этом никакие suphp и suexec не юзаются и всё работает шоколадно.

На тех серверах где установленн suphp нет возможности поставить 777. А там где нет - милости просим, нас не касатется что творится на пользовательских акаунтах.

А.. дых это еще в дремучие годы в suexec-е патчили ;)
Вот и получается, что это не политика бе-опасности хостера, а политика безопасности разработчиков suexec/suphp

fastcgid - юзер ставит себе права, какие хочет, хоть 700, хоть 777

У нас PHP FastCGI + SuPHP, посему выше 755 поставить не выйдет, будет 500-я ошибка. 777 - это вообще бред на любом шаред хостинге. Любой может записать в такой файл что угодно. "Пара строк на перлятине всех рассудит" - видал я как-то цитату, полностью поддерживаю это мнение Клиентам мы вообще рекомендуем ставить 0600 на все конфигурационные скрипты и прочее, что хранит конфиденциальную инфу (да и не только - можно на все php скрипты поставить 600 и не будет никаких проблем). При таком раскладе никакой ломакер с соседнего аккаунта не прочтет содержания. По идее все логи ошибок php и т.п. тоже должны иметь 600 права. Ни к чему всем сподряд знать, какие проблемы имеет движок.

P.S. И вообще, солидарен с вышесказанным, что все глупые неурядицы по поводу "необходимых 777 прав на запись" - вина в первую очередь разработчиков и тех, кто пишет мануалы. Тем, кто пишет ПО, необходимо знать и представлять, как оно будет в итоге работать на реальном сервере, а не на их домашнем "денвере".

#mkdir /home/user
#touch /home/user/file
#chown -R user.user /home/user
#chmod 700 /home/user
#chmod 777 /home/user/file
#su user1
user1$ ... ну записывайте в /home/user/file.. или прочитайте его хотя бы

Это всего лишь одно частное исключение. Не во всех случаях представляется возможным установить 700 права на домашнюю директорию пользователей. У нас например это минимум 701. Причина - почта хранится внутри. Юзверю mail как-то надо попадать туда и считывать файлы в Maildir.

Это не исключение, это правило, которое звучит как "не пускать пользователей внутрь дома других пользователей должна дверь". Для почтальонов и прочих представителей сервисных служб можно делать исключения... но не для всех пользователей системы.

Пардон, мысль немного не закончил. Структуру домашней директории в директадмине помните? Собственно в домашнюю директорию доступ есть у всех по вышеназванной причине. Права 711 на неё. А вот на всех директориях вида /home/user/domains/domain.ru права 750. То есть доступа собственно к данным по умолчанию нет. Соответственно, если какие-то файлы размещаются выше, в самой папке /home/user, то рекомендуем chmod 600 на них. Ну и из параноидальных соображений можно на конфиги, логи и прочее тоже поставить

А что, почта не может сделать suid в юзера перед входом?

Теоретически наверно может. Я dovecot глубоко не копал. Просто стоит ли это того? Файлы пользователей при текущем положении вещей в сохранности и хорошо. По умолчанию в домашней директории ничего ценного нету, если только юзверь сам не положит. Но опять-таки, чтобы что-то оттуда стянуть, надо как минимум знать как файл зовется. Листинг файлов получить не выйдет. SSH выдаем только jail.

Локальных бутфорсеров, которые ищут "как файл зовется" еще не встречали?

Встречали, и php/perl шеллы встречали В корне хоумдира пущай ищут, не найдут ничего, а дальше не заползти физически, chmod не даст.