2013-10-24 60 views
1

我一直在搜索整个网站的解决方案,但一直没有找到。我有一个Apache 2.2.15,Django 1.6和mod_wsgi 3.2的CentOS 6.4服务器。我使用Apache来显示静态文件和mod_wsgi来显示Django内容。使用Django应用程序在Apache服务器上发生403错误

由于this page,我将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。我在/srv目录上运行了ls -l,其所有者和组被列为root。所以,我跑sudo chown -R apache:apache /srv/mysite它改变了目录和所有子目录使用apache作为所有者和组。

但是,无论我有多少Google或尝试,我都无法克服这个403错误。

编辑:

我发现,当我禁用SELinux,并在http.conf文件WSGIPythonPath变量是django.wsgi,它导致500内部服务器错误。但是,当我将其更改为wsgi.py时,我的网站正常显示。我很好奇这是为什么。在任何情况下,因为这将是一台生产机器,所以我宁愿保留SELinux并找出如何获得适当的权限。

编辑2:

我已经编辑我的django.wsgi文件(上述变更)ALA this link

编辑3:

我试图移动我的项目文件到我的/ home /文件夹。我一直在尝试django.wsgiwsgi.py之间交替,但仍无法通过403 Forbidden错误。我以为它最初是一个权限问题与/srv目录,但它似乎并非如此...我试图找出这一点,但没有任何工作。

编辑4:

我决定只坚持开发服务器现在...但我仍然需要得到这个工作,我在我的绳子结束。有没有人可以帮助我?

回答

3

SELinux有自己的系统授予访问权限。根据SELinux上下文,必须授予您的进程访问文件系统上的文件。在SELinux中定义了一些默认的政治和上下文,这些默认的政策和上下文在安装的默认情况下是有用的。预计网络文件将在'/ var/www'中。你可以多为检查文件的当前环境或使用交换机处理“-Z”,见

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

检查/ SRV/mysite的

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

执行Apache服务器允许访问的文件上下文通过SELinux类型httpd_sys_content_t,不允许使用SELinux类型var_t访问文件。

1.更改SELinux的类型,目录和检查方面

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

检查,如果你的网站是工作现在。

到现在为止它还没有完成,而您将文件系统重新标记为默认值,或者如果您使用守护进程检查或重新标记自身,则可能会失去新标记。

2.默认labaling的目录

创建由“semange”默认标签,并通过“的restorecon”

[[email protected]]# semanage fcontext -a -t httpd_sys_content_t /srv/mysite 
[[email protected]]# restorecon -v -R /srv/mysite 
[[email protected]]# 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访问。


更多在红帽: 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/

+0

感谢这个答案,对不起这个答复是这么晚。我遵循你的第一步,这非常有效。然后我继续步骤2,但之后,该网站不再工作,让我回到相同的403错误。我还注意到'ls -Z/srv'的输出是'system_u:object_r'而不是'unconfined_u:object_r'。这种差异很重要吗? – noblerare

+0

如果您使用的是目标策略(即类型强制策略),则system_u和unconfined_u SELinux用户之间没有区别,因为只检查了SELinux类型。如果步骤2不起作用,则'ls -Z/srv'的默认标签检查SELinux上下文有另一个规则,并通过'semanage fcontext -l | grep/srv'检查缺省标签。 –

相关问题