- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Да, и за разрешение доступа апачем как раз дают права. Ведь если поставить 640 скажем, файл просто не прочитается, верно? И, соответственно, не будет отображен... почему и ставят 644 обычно на файлы (чтобы оно читалось апачем). И, собственно, в режиме mod_php защищать должен open_basedir... Но тут начинается другой момент: если поддержки PHP на домене нет, панелька не прописывает openbasedir для виртуалхоста. А раз так - то подключается модуль в .htaccess... А вот если подключен cgi глобально, это еще может привести к 500 (от так). Соответственно, если openbasedir для виртуалхоста не прописывается панелью из-за cgi/fcgi, начинаем часто думать над правами (а должен ли этот файл читать апач)...
Ещё раз говорю, open_basedir не защитит от shell-функций, если они не запрещены. Но есть другие варианты их вызова, через вроде бы безобидные функции.
Вот на тему "должен ли файл читать apache - верно". Точнее должен ли его читать nginx. Apache (юзеру) не нужно читать php-файлы, они должны открываться с правами владельца сайта. Но при использовании nginx, он должен иметь возможность открывать статические файлы и естественно иметь доступ к папке с файлами. А nginx часто работает под тем же юзером, что и apache (www или www-data)
Да, если апач работает в режиме префорк, можно запретить mod_php... оставить только сиджиай. У меня даже если апач переведу в префорк, такая записочка в >htaccess даст 500, т.к. я еще полгода назад перевел всех на cgi...
А если мы добавим www-домен с "без поддержки php" ?) Тогда никаких 500 не будет.
Вырубить mod_php можно, но вот тот же phpmyadmin нужно будет заставить корректно работать при cgi.
Если там для работы хватает прав 700/600, и umask по умолчанию стоит для этих прав - юзерам незачем будет делать chmod, ибо все работает и так.
У всех файлов права апача и опенбазедир чтоли? ну вариант.
Andreyka, Евстественно, млин. Собери кумайл с включенным SELinux - будешь большой молодец.
А ты умный. Я как раз готовлю к продаже правила для selinux targeted. Там будет множество софта, в том числе и кумыло.
Только одно - для selinux ничего собирать ненадо, он работает с уже собранным софтом на уровне ядра и правил. Это так, для общего развития.
У всех файлов права апача и опенбазедир чтоли? ну вариант.
1. Права apache у всех файлов? Тогда все и читаются им же.
2. open_basedir тут чем поможет?
А если мы добавим www-домен с "без поддержки php" ?) Тогда никаких 500 не будет.
Не по умолчанию конфиг. Для всех принудительно сиджиай прописан.
но вот тот же phpmyadmin нужно будет заставить корректно работать при cgi.
верно.
Raistlin добавил 24.12.2010 в 09:57
open_basedir тут чем поможет?
Ну как.... Запретит из этого виртуалхоста выходить за пределы его директории.
Анекдот... по дефолту друпал с mod_Php не может попасть в /tmp, хотя пытается (если ispmanager ставить). Собственно, работа openbasedir... Щас не знаю, т.к. конфиги не смотрел какие исп создает с mod_php.
Ну как.... Запретит из этого виртуалхоста выходить за пределы его директории.
Попробуйте echo exec('ls -la /var/www'); (или даже echo exec('ls -la /'); ) и посмотрите. (хотя от настроек и прав зависит. Но не от basedir)
Himiko добавил 24.12.2010 в 10:03
Анекдот... по дефолту друпал с mod_Php не может попасть в /tmp, хотя пытается (если ispmanager ставить). Собственно, работа openbasedir... Щас не знаю, т.к. конфиги не смотрел какие исп создает с mod_php.
Всё верно. Проблема, потому что он пытается сделать это через функции php, а не через shell-функции.
ууупс... от блин. Собственно openbasedir тоже не спасет. Andreyka, как так? itk?
chroot 😂
А вообще - itk уже не даст mod_php запустить с правами www.
Остаётся только корректные права ставить. И конфиги лучше держать с правами 600, они, кроме как юзеру сайта, не нужны.
Если на сервере стоит nginx, то ставить umask 0027 на файлы и директории нельзя! Он не прочтет их!
umask 0022 и mod_php от пользователя через модули или через патч. nginx на другом пользователе и группе. chmod 710 и chgrp nginxgroup на веб-директорию, и ничего уже чужими пользователями выше этой директории не читается. Апач читает выше, потому что пользователь, а nginx потому что группа.
Если у Вас в SSH файлы можно прочесть
sudo -u apache cat /home/user/web/index.php
значит у Вас дырень в настройках прав.
Если у Вас в SSH файлы можно прочесть
sudo -u apache cat /home/user/web/index.php
значит у Вас дырень в настройках прав.
Потёр... сразу не понял смысла...