Права доступа на файлы и папки

[Mavn]

Права на файлы и папки при установки форума:
attachments         777
Packages              777
-temp                    777
-backups               777
-installed.list         777
Sources                777
Themes                 777
Settings.php         777
Settings_bak.php 777
в отдельных случаях на папку куда устанавливается форум.

Для работы форума
attachments 777
в случае если вы изменяете настройки форума нужно выставить права:
Settings.php 666
Settings_bak.php 666
в остальных случаях:
Settings.php 644
Settings_bak.php 644
в отдельных случаях:
Settings.php 600(400)
Settings_bak.php 600(400)
для более подробной информации о том что такое права доступа на файлы(chmod) читайте здесь

При установке модов:
1. Посмотрите на офф сайте при помощи парсера модов какие файлы изменяет мод, и с какими папками он будет работать, распаковывая файлы. Например мод распаковывает файлы в папку /Themes/default/languages соотвественно все данные папки должны иметь права на запись т.е. права на папки будут 777 для всех папок. Themes 777, default 777, languages 777.
2. Для упращения установки можно выставить на все файлы и папки права на запись 777.
3. Даже в случае установки прав на запись для всех папок и файлов установщик модов может ругаться на то что вроде права доступа не установлены, это может быть связано с тем что сам форум не может создать папку /Packages/temp, либо создает но права на папку меньше чем необходимо для правильной работы форума, для того чтобы у нас не возникало проблем с данной папкой, можно установить мод No Temp Directory Removal. Есть и другой способ решения данной проблемы, создать файл и вставить права на файл 000 внутри /Packages/temp, но далеко не все хосты позволяют выставлять на папки или файлы chmod 000.

[supmener]

А если у меня, как на скриншоте файлы показаны, что при 644 пишуться. Значит ли это, что не надо на них выставлять 777?

[Mavn]

для одних 666 мало подавай 777 другим 644 вполне нормально для изменений, все зависит от настроек хоста. Если форум не ругается на нехватку прав доступа то можешь и не парится  с этим.

[k_ok_o_s]

  На последнем этапе установки 2RC3 получил сообщение:

Поздравляем, процесс установки завершен! ... Директория установки имеет права на запись. В целях безопасности рекомендуется сделать ее доступной только для чтения.

Директория установки (WWW) у меня имеет права 750. Внутри этой папки все файлы имеют 644, папки 755. (Кстати, после первой закачки файла фользователем на форум, папка attachments стала 777.)
Что, надо поменять права на директорию WWW?
 

[Mavn]

на некоторых серверах даже при 644 755 файлы все равно имеют права на запись! Так что если уверен что у тебя все нормально не парься

[Elrond604]

А подскажите какой-нибудь простой способ проверки файла на запись.

[Mavn]

посмотреть его права

[Солярис]

Уважаемые, перечитал данную тему несколько раз, но так до конца не понял, какие права установить на папки и файлы для работающего форума (для обеспечения максимальной безопасности и для исключения возможности несанкционированного доступа)?

Заранее спасибо за ответ.

[Макар]

Солярис, универсального ответа нет. Зависит от хостинга. У меня например на одном хостинге все прекрасно работает при 755 для папок и 644 для файлов, а на другом этих прав мало, подавай 777 на папки кеш, аватар, аттач. Файл settings.php при 644 незаписываемый, каждый раз приходится менять права, а на первом хостинге при 644 пишется.

И как по мне первый хостинг безопаснее, так как скрипт смф работает на нем отлично, права на файлы я руками не перевожу, и нет случайной вероятности (во сказал) по запарке оставить на каком то важном файле 777 .............

[cdroller]

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

[Mavn]

лучше не стоит
если пользователь апач это будет означать что любой пользователь знающий путь к файлу сможет получить доступ к файлу а следовательно или изменить его или прочитать(например подключение к бд) что повлечет еще большие проблемы

[cdroller]

ух как я запарился с этими правами, не работало под пользователем и все тут

например смена chmod через Менеджер пакетов -> Права доступа на файлы

приводило к ошибкам типа
домен/index.php?action=admin;area=packages;sa=perms;сессия
2: closedir(): supplied argument is not a valid Directory resource
Файл: путь/Sources/Packages.php

readdir(), opendir и т.п.

эти ошибки возникают когда скрипт пытается произвести какие-либо манипуляции с директориями ... но либо этих директорий не существует, либо у скрипта недостаточно прав. В моем случае первое отпадает, я точно знаю что они существуют, а также я выставил для них права все нужные ... НО скрипт работает не под пользователем, под которым я файлы закачал, а под пользователем apache, к такому выводу я пришел ... как его заставить работать под пользователем виртуал-хоста? на шаред хостинге об этом чаще всего заботятся админы и сразу делают как надо ... но у владельцев ВПС и дедиков могут возникать такие же как у меня проблемы, когда Apache установлен по дефолту ... и также у меня не был включен suEXEC и никакого желания компилить PHP и запускать как CGI тоже не было

но в ПС быстро нашлось отличное решение Apache MPM-ITK, это патч к стандартному apache, который позволяет запускать скрипты, выполняемые вебсервером (например php в режиме как модуль apache) с правами пользователя-владельца виртуального хоста, а не web-серверу.

и дока для моей CentOS по установке нашлась тоже хорошая http://wiki.firstvds.ru/index.php/Apache_MPM-ITK_%D0%BD%D0%B0_CentOS_%D1%81_ISPmanager

FreeBSD http://ru.ispdoc.com/index.php/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_Apache_MPM-ITK

в общем то с репо воткнулось все через yum и сразу все проблемы с правами исчезли, картинка такая же как у  supmener выше ... с любыми chmod работает, скрипты теперь запускаются от имени пользователя виртуал-хоста, как и должно быть ...

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

а кроме того может потребоваться php_admin_value open_basedir none сделать или прописывать все пути, а то будут сыпаться часто ошибки типа open_basedir restriction in effect, не есть гуд когда скрипты могут лазить где угодно, ну ничего не поделать, если хочется чтоб норм все с админки работало приходится чем то жертвовать ... хотя если скрипты не дырявые то криминала нет

[Макар]

Пост можно грохнуть )

как по мне, лучше б ты расписал все без использования сленга, что бы будущие поколения смогли воспользоваться твоим опытом решения проблемы ...........

[Кирдык-батыр]

В общих чертах, хост настраивать  SuExec + suPHP
а не просто mod_php
под mod_php можно взломать всех.

[Mavn]

если один на хосте то особо смысла не вижу настраивать да и при правильной расстановке прав на домашние директории и настройке апача дальше своей директории все равно никто не вылезет

[Quesabe]

Подскажите права на dreamportal. Не получается установить модуль.

[Mavn]

смотрите какие файлы изменяет мод и соответственно выставьте права на файлы и папки

[Серый Лис]

Прочитал, немного вник. Спасибо Мавну за исчерпывающую информацию.
Прав Макар..  Зависит от хостинга. Заказывал у хостера проверку на вирусняки и уязвимости, советует изменить права на группу файлов и директорий, ибо существует потенциальная уязвимость. Трудно сказать.. хорошо то, что хорошо кончается и потенциальная уязвимость так и останется в этом (варианте) не превратившись в мгновение ока в реальную.
Пока проблем нет, а совет приму к сведению.

[eugenr]

После переезда выскочила подобная ошибка. При загрузке аватаров.
Долго пытался мудрить с правами на папки но результата не дало.
Потом обратил внимание на путь к папке, он остался с старого сервера.
repair_settings его просто не заметил и не исправил. Заменил там же руками, записал, и все заработало.