SELinux致使Apache 403错误解决方法

将DocumentRoot设在/var/www/html下能够访问

可是将DocumentRoot设在其余目录（如：/webroot）下就出现Forbidden了。在./etc/httpd/conf/httpd.conf中的相关部分是这样的：

Alias /query "/home/query"

<Directory "/home/query">

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

可是在浏览器中输入：http://localhost/query/ 时，出现Forbidden：

Forbidden

You don't have permission to access /query on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.0.52 (Red Hat) Server at localhost Port 80

对于刚使用Redhat Enterprise Linux4 或Fedora Core 2以上/CentOS 4的用户，必定会为Apache常常没法正常运转，报以"Permission denied"等错误而大为不解，甚至大为恼火。

其实这是由于这些系统里激活了SELinux，而用户的apache配置与SELinux的配置策略有抵触产生的，只有经过适当调整，使apache的配置和访问符合策略才能正常使用。

如今下面来分析一下SELinux中有关httpd（apache）的context定义（略有删节）

/home/[^/]+/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_user_content_t

/var/www(/.*)? system_u:object_r:httpd_sys_content_t

/var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t

/usr/lib/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t

/var/www/perl(/.*)? system_u:object_r:httpd_sys_script_exec_t

/var/www/icons(/.*)? system_u:object_r:httpd_sys_content_t

/var/cache/httpd(/.*)? system_u:object_r:httpd_cache_t

/etc/vhosts -- system_u:object_r:httpd_config_t

/usr/sbin/httpd -- system_u:object_r:httpd_exec_t

/usr/sbin/apache(2)? -- system_u:object_r:httpd_exec_t

/usr/sbin/suexec -- system_u:object_r:httpd_suexec_exec_t

/var/log/httpd(/.*)? system_u:object_r:httpd_log_t

/var/log/apache(2)?(/.*)? system_u:object_r:httpd_log_t

/var/log/cgiwrap.log.* -- system_u:object_r:httpd_log_t

/var/cache/ssl.*.sem -- system_u:object_r:httpd_cache_t

/var/cache/mod_ssl(/.*)? system_u:object_r:httpd_cache_t

/var/run/apache(2)?.pid.* -- system_u:object_r:httpd_var_run_t

/var/lib/httpd(/.*)? system_u:object_r:httpd_var_lib_t

/var/lib/php/session(/.*)? system_u:object_r:httpd_var_run_t

/etc/apache-ssl(2)?(/.*)? system_u:object_r:httpd_config_t

/usr/lib/apache-ssl(/.*)? -- system_u:object_r:httpd_exec_t

/usr/sbin/apache-ssl(2)? -- system_u:object_r:httpd_exec_t

/var/log/apache-ssl(2)?(/.*)? system_u:object_r:httpd_log_t

/var/run/apache-ssl(2)?.pid.* -- system_u:object_r:httpd_var_run_t

/var/run/gcache_port -s system_u:object_r:httpd_var_run_t

/var/lib/squirrelmail/prefs(/.*)? system_u:object_r:httpd_squirrelmail_t

/usr/bin/htsslpass -- system_u:object_r:httpd_helper_exec_t

/usr/share/htdig(/.*)? system_u:object_r:httpd_sys_content_t

/var/lib/htdig(/.*)? system_u:object_r:httpd_sys_content_t

针对上述的内容，能够对以下的几个常见问题进行简单处理：

1.phpmyadmin在非默认/var/www/html目录下没法运转

一般相似的状况都是在配置了虚拟主机时，访问/phpmyadmin等提示403访问拒绝，日志里也提示Permission denied，这是由于phpmyadmin防止的目录及文件自己属性不符合context要求。

假设phpmyadmin放在/web目录下，那么执行:

chcon -R -t httpd_user_content_t /web

则会令/web及其下全部子目录/文件，包括phpmyadmin文件都得到了httpd_user_content_t的属性，若是其传统的Unix属性对httpd来讲是可读的话，再从新访问一下就应该能够了。

2./home目录下的虚拟主机没法运转

与问题1也是相似的，不过根据上文中context的定义，/home目录下必须是用户的$HOME/www或public_html或web目录才是 httpd_user_content_t类型，所以建议将要做为web页面的内容放置在用户的$HOME/www或web或public_html里，并确保其属性是httpd_user_content_t，使用以下命令查看：

ls -Z /home/abc/

drwxr-xr-x abc abc user_u:object_r:user_home_dir_t tmp

drwxrwxr-x abc abc user_u:object_r:httpd_user_content www

如不是，则可经过chcon来逐级目录及文件更改，直至最后能访问：

chcon -R -t httpd_user_content_t /home/abc/web

chcon -t user_home_dir_t /home/abc

3.CGI程序没法运行

若是cgi程序放在/var/www/cgi-bin/里也没法执行，遇到403或500错误的话，能够检查cgi 程序的属性，按SELinux contexts文件里定义的，/var/www/cgi-bin/里必须是httpd_sys_script_exec_t 属性。经过ls -Z查看，若是不是则经过以下命令更改：

chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/*.cgi

若是是虚拟主机里的cgi，则参考问题2使之能正常使用普通的功能后，再经过chcon设置cgi文件的context为httpd_sys_script_exec_t便可。

4.Setuid/gid 程序没法运行

例如早期的SqWebMail及qmailadmin等，须要setuid/gid的支持，但在SELinux下这将受到严格限制。第一种方法是比较完全的办法，能保留系统的安全性，经过：

audit2allow -l -i /var/log/messages

将SELinux拒绝的信息转换为相应的policy allow指令，将这些指令添加到SELinux policy 的src里相应的配置文件，从新生成policy并加载。但这样作相对比较麻烦。

另外一个方法最简单，但将使apache得不到保护。首先肯定SELinux 类型是targeted的：

cat /etc/selinux/config|grep SELINUXTYPE

而后，使apache脱离SELinux保护：

setsebool -P httpd_disable_trans 1

而后重启动apache：

/etc/init.d/httpd restart

这样全部apache强制的检查都失效，须要setuid/gid的程序能够正常使用。但这样带来了增长漏洞的危险，对于迫切须要运行而又很急的状况，本方法是一个最大限度减小系统安全缺失的最后办法。对于取消SELinux 未必是一个好方法。