redhatEnterprise4下的apache怎麼訪問別的目錄?

wuhuizhong發表於2007-04-19

將DocumentRoot設在/var/www/html下可以訪問
但是將DocumentRoot設在其他目錄(如:/webroot)下就出現Forbidden了。
在./etc/httpd/conf/httpd.conf中的相關部分是這樣的:
Alias /query "/home/query"

Options Indexes MultiViews
AllowOverride None

Order allow,deny
Allow from all

但是在瀏覽器中輸入:
時,出現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

[@more@]

對於剛使用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 未必是一個好方法。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/72950/viewspace-911562/,如需轉載,請註明出處,否則將追究法律責任。

相關文章