Ошибка 403 на сервере Apache с приложением Django

Я искал на этом сайте решение, но не смог его найти. У меня есть сервер CentOS 6.4 с Apache 2.2.15, Django 1.6 и mod_wsgi 3.2. Я использую Apache для отображения статических файлов и mod_wsgi для отображения содержимого Django.

Я поместил файлы проекта Django в каталог /srv из-за этой страницы. .

Когда я запускаю сервер разработки Django, тестовая страница, которую я написал, отображается правильно. Однако, когда я запускаю свой сервер Apache и посещаю 127.0.0.1, я получаю ошибку 403 Forbidden.

django.wsgi (в /srv/mysite)

import os
import sys

envpath = '/usr/lib/python2.6/site-packages'

pwd = os.path.dirname(os.path.abspath(__file__))
os.chdir(pwd)
sys.path = [env] + sys.path

os.environ['PYTHON_EGG_CACHE'] = '/srv/mysite/.python-egg'
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'

site.addsitedir(envpath)

from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandlers()

httpd.conf

WSGIScriptAlias / /srv/mysite/django.wsgi
WSGIPythonPath /srv/mysite
<more aliases and tags in order to get the right static files to show>

В файле httpd.conf указанный пользователь и группа по умолчанию являются apache. Я запустил ls -l в каталоге /srv, и его владелец и группа были указаны как root. Итак, я запустил sudo chown -R apache:apache /srv/mysite, который изменил каталог и все подкаталоги, чтобы использовать apache в качестве владельца и группы.

Однако, сколько бы я ни гуглил и ни пытался, я не могу справиться с этой ошибкой 403.

ИЗМЕНИТЬ:

Я обнаружил, что когда я отключаю SELinux, а переменная WSGIPythonPath в файле http.conf равна django.wsgi, это приводит к ошибке 500 Internal Server. Однако, когда я изменяю его на wsgi.py, мой веб-сайт отображается правильно. Мне интересно, почему так.

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

РЕДАКТИРОВАТЬ 2:

Я отредактировал свой файл django.wsgi (измененный выше) аля эта ссылка

ИЗМЕНИТЬ 3:

Я попытался переместить файлы проекта в папку my/home/. Я чередовал попытки django.wsgi и wsgi.py, но все еще не могу пройти мимо ошибки 403 Forbidden. Я думал, что изначально это была проблема с правами доступа к каталогу /srv, но оказалось, что это не так... Я пытаюсь понять это, но ничего не работает.

ИЗМЕНИТЬ 4:

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


person noblerare    schedule 24.10.2013    source источник


Ответы (1)


SELinux имеет собственную систему предоставления доступа. Вашему процессу всегда должен быть предоставлен доступ к файлам в файловой системе в зависимости от контекста SELinux. В SELinux определены некоторые политики и контексты по умолчанию, которые полезны для случаев вашей установки по умолчанию. Ожидается, что только веб-файлы будут находиться в «/var/www». В основном вы можете проверить текущий контекст файлов или процессов, используя ключ «-Z», см.

[root@localhost]#  ls -Z /var
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 www

Проверьте контекст /srv/mysite

[root@localhost]#  ls -Z /srv
drwxr-xr-x. root root system_u:object_r:var_t:s0       mysite

HTTPD-серверу Apache разрешен доступ к файлам с типом SELinux httpd_sys_content_t, а НЕ разрешен доступ к файлам с типом SELinux var_t.

<сильный>1. Измените тип SELinux для своего каталога и проверьте контекст

[root@localhost]#  chcon -R -t  httpd_sys_content_t /srv/mysite
[root@localhost]#  ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite

Проверьте, работает ли ваш веб-сайт прямо сейчас.

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

<сильный>2. Сделайте ярлыки по умолчанию для вашего каталога

Создайте маркировку по умолчанию с помощью «semange» и примените ее к своему каталогу с помощью «restorecon».

[root@localhost]#  semanage fcontext -a -t httpd_sys_content_t /srv/mysite
[root@localhost]#  restorecon -v -R /srv/mysite
[root@localhost]#  ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite

Прямо сейчас ваша маркировка SELinux исправлена.

Примечание. Регулярные выражения могут определять контекст по умолчанию.

Debian: я не являюсь пользователем Debian, поэтому тип SELinux может немного отличаться, принцип тот же самый, проверьте тип SELinux вашего каталога apache и установите его для нужного вам каталога. быть доступным из apache.


Подробнее читайте на сайте RedHat: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html

Документация по Fedora SELinux: http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/

person Martin Strejc    schedule 04.11.2013
comment
Спасибо за этот ответ и извините, что этот ответ так поздно. Я следовал вашему первому шагу, который сработал чудесно. Затем я перешел к шагу 2, но после этого веб-сайт больше не работал, возвращая мне ту же ошибку 403. Я также заметил, что вывод ls -Z /srv равен system_u:object_r вместо unconfined_u:object_r. Эта разница важна? - person noblerare; 07.01.2014
comment
Если вы используете таргетированную политику (то есть политику принудительного применения типа), нет никакой разницы между пользователем system_u и unconfined_u SELinux, потому что проверяется только тип SELinux. Если шаг 2 не работает, существует другое правило для проверки маркировки по умолчанию контекста SELinux с помощью «ls -Z /srv» и проверки маркировки по умолчанию с помощью «semanage fcontext -l|grep /srv». - person Martin Strejc; 07.01.2014