Correctly, настраивающий apache2 полномочия в /var/www/example.com
Это ожидается при попытке установить приложения Fedora непосредственно в CentOS. Это следует из Fedora, имеющего более актуальные приложения и библиотеки.
У Вас есть несколько из выбора:
Установите openssl от Fedora и надейтесь, что он не разрушает другой ssl использование приложений - НЕ РЕКОМЕНДУЕМЫЙ!
Захватите исходного об/мин от Fedora и создайте Ваш собственный пакет текущие библиотеки пользующегося CentOS.
Проверьте один из стороннего repo's CentOS и посмотрите, доступен ли mysecureshell через одного из них.
Проверьте rpmfind или одного из его кузенов и посмотрите, можно ли получить об/мин через них.
При нахождении об/мин удостоверьтесь, что он соответствует архитектуре CentOS (32 бита, 64 бита, и т.д.).
Я использую apache-itk с отдельным пользователем для каждого сайта. Это дополнительные накладные расходы, поскольку каждый новый запрос должен запускать новый процесс от имени этого пользователя, но это действительно делает вещи намного более аккуратными с точки зрения безопасности, поскольку один конкретный сайт не может получить доступ к файлам другого. Это также помогает, если один конкретный сайт потребляет слишком много ресурсов и т. Д.
В Debian / Ubuntu:
apt-get install apache2-mpm-itk
Затем добавьте:
<IfModule mpm_itk_module>
AssignUserId USER GROUP
</IfModule>
В VirtualHost вашего apache2, заменив USER и GROUP своими собственными.
Способ настройки разрешений зависит от вашей модели безопасности и угроз. И мы не знаем, что это такое.
Но в целом файлы / каталоги должны быть доступны для чтения только тем uid, которые должны их читать, и должны быть доступны для записи только тем uid, которые должны их записать. Иногда не всегда практично отображать непосредственно в модель разрешений Unix, поэтому обычно применяется следующий принцип: случайное раскрытие информации обычно предпочтительнее несанкционированного изменения данных.
В вашем случае это означает, что ни один из файлы / каталоги в дереве документов веб-сервера должны быть доступны для записи с помощью uid веб-сервера. В некоторых случаях это может повлечь за собой монтирование файловой системы только для чтения. Но, очевидно, это усложняет жизнь, когда вы хотите изменить свой контент. Итак, кто меняет содержание? Если это один пользователь (и всегда будет один пользователь), тогда ваши разрешения могут быть следующими:
-rw-r----- devuser wwwuser somefile
drwxr-s--- devuser wwwuser somedir
Итак, ваш веб-сервер получает доступ через групповое владение. Бит липкой группы гарантирует, что созданные каталоги / filse наследуют одну и ту же группу.
Если у вас есть несколько пользователей, изменяющих файлы, добавьте их всех в группу (скажем, webdev) и сделайте доступ к веб-серверу через «другой» разрешения:
-rw-rw-r-- devuser webdev somefile
drwxrxsr-x devuser webdev somedir
Конечно, есть дополнительные инструменты, которые могут добавить дополнительное разделение привилегий, но я бы рассмотрел их только в том случае, если вы настраиваете общий хост и вам нужно изолировать каждый виртуальный хост.
Если вы единственный, кто использует веб-сервер, то такие вещи, как mpm_itk, будут излишними.
Просто установите разрешения для того же пользователя, от имени которого работает веб-сервер / php (www -user: www-user в вашем случае).
Единственная причина изолировать разрешения - защитить один сайт от взлома, если веб-сервер, на котором запущен другой сайт, также будет взломан. Если все сайты ваши, то это далеко не такая большая проблема.
Я вижу много-много пошаговых руководств, которые, кажется, подразумевают, что вы должны установить такую безопасность, а не делать этого опасно. Это совершенно неверно. Пользователь www-user не имеет разрешений ни на что на вашем сервере, кроме каталога вашего веб-сервера, поэтому совершенно безопасно оставить корневой веб-сайт и все, что ниже него, установлено на 770/660 и www-user: www-user.
Худший случай,