Apache 403错误&SELinux解决方案
2017-01-07 21:48
323 查看
初次搭建Apache服务器,在/var/www/html目录下测试正常,然后在普通用户的/home/目录下建立public_html存放html文件,用浏览器访问时出现403 Forbidden 错误。
这个问题与SELinux有关,SELinux是一种安全策略机制,它限制了进程只能访问跟它自己有关的文件或目录(大意),即便文件或目录的权限设置都正常,SELinux的安全策略还是会继续检查是否可以访问,因此,由于普通用户建立的html主页其文件策略类型是user_home_t,而Apache的进程所使用的SELinux安全策略要求只能访问httpd_sys_content_t策略类型的文件/目录,所以造成了403错误。
解决办法:
#chcon -R -t httpd_sys_content_t /home/普通用户名/public_html/
然后可以用ls -laZ来查看文件/目录的策略类型,之后在这个目录中生成的文件,其安全策略类型会自动设为httpd_sys_content_t。
原文链接:
Apache
(httpd) 403 errors & SELinux in FC3
Posted by jwigdahl @ 17 Nov 2004 10:38 am
Quick fix:
Now for the meat:
So in Fedora Core 3 we now have SELinux enabled by default in the installation. I decided to leave it enabled because security is a "Good Thing" (right?) and I knew I was going to have to get familiar with it at some point. So this was all fine and good until
I ran into the first piece of the system I wanted to work with that was affected by the default policy that's called "targeted".
The "targeted" policy confines certain network daemons to run in their own specific "security domain". These daemons include dhcpd, httpd (apache), named, nscd, ntpd, portmap, snmpd, squid, and syslogd.
When I setup apache on a system where it wil be utilized, I have a habit of not using /var/www/html as my starting point for document roots, but rather create a dir at /home/websites and place my document roots in there. In the good ol' days of Discretionary
Access Controls (DAC) just making sure that apache had the perms it needed to read the documents in there was enough (using chmod, chown, and the like).
Not so with SELinux enabled. In addition to the regular DAC we're all used to, we now have Mandatory Access Controls (MAC) that define security contexts for files/directories etc. Turns out it looks like by default, apache only has access to /var/www/html when
it's fired up.... I'm guessing that and probably /var/log/httpd (which is exactly as it should be). To enable apache to view my files in /home/websites, I had to apply a new security context to these files. The answer to this is the chcon command.
To be brief, the full command I executed was:
chcon -R -t httpd_sys_content_t /home/websites
After executing this, apache could read my files.
Important links I found in troubleshooting:
http://fedora.redhat.com/docs/selinux-apache-fc3
http://fedora.redhat.com/docs/selinux-faq-fc3/
http://lwn.net/Articles/105409/
I like where this SELinux thing is going. Permissions done right, for sure. This doesn't come with out growing pains though. It's complex (or so it seems to me after only working with it for a couple days) and will take some time to learn. I'm prepared for
some frustration....
Now many of you are probably asking yourself why would anyone (let alone me) want to bother with this? Well I think a simple example of one
4000
of the cool things is that even though something like /etc/passwd has DAC octal perms of 644 (rw-r--r--), apache still
can't read it because that file is not with in apache's security context. So any users on your system can't write a little script that reads your /etc/passwd file and basically posts it on a web page for the world to see (giving potential crackers a list of
valid user accounts on the system).
UPDATE: Thanks for the updated link Bob.
这个问题与SELinux有关,SELinux是一种安全策略机制,它限制了进程只能访问跟它自己有关的文件或目录(大意),即便文件或目录的权限设置都正常,SELinux的安全策略还是会继续检查是否可以访问,因此,由于普通用户建立的html主页其文件策略类型是user_home_t,而Apache的进程所使用的SELinux安全策略要求只能访问httpd_sys_content_t策略类型的文件/目录,所以造成了403错误。
解决办法:
#chcon -R -t httpd_sys_content_t /home/普通用户名/public_html/
然后可以用ls -laZ来查看文件/目录的策略类型,之后在这个目录中生成的文件,其安全策略类型会自动设为httpd_sys_content_t。
原文链接:
Apache
(httpd) 403 errors & SELinux in FC3
Posted by jwigdahl @ 17 Nov 2004 10:38 am
Quick fix:
chcon -R -t httpd_sys_content_t <path to web files>
Now for the meat:
So in Fedora Core 3 we now have SELinux enabled by default in the installation. I decided to leave it enabled because security is a "Good Thing" (right?) and I knew I was going to have to get familiar with it at some point. So this was all fine and good until
I ran into the first piece of the system I wanted to work with that was affected by the default policy that's called "targeted".
The "targeted" policy confines certain network daemons to run in their own specific "security domain". These daemons include dhcpd, httpd (apache), named, nscd, ntpd, portmap, snmpd, squid, and syslogd.
When I setup apache on a system where it wil be utilized, I have a habit of not using /var/www/html as my starting point for document roots, but rather create a dir at /home/websites and place my document roots in there. In the good ol' days of Discretionary
Access Controls (DAC) just making sure that apache had the perms it needed to read the documents in there was enough (using chmod, chown, and the like).
Not so with SELinux enabled. In addition to the regular DAC we're all used to, we now have Mandatory Access Controls (MAC) that define security contexts for files/directories etc. Turns out it looks like by default, apache only has access to /var/www/html when
it's fired up.... I'm guessing that and probably /var/log/httpd (which is exactly as it should be). To enable apache to view my files in /home/websites, I had to apply a new security context to these files. The answer to this is the chcon command.
To be brief, the full command I executed was:
chcon -R -t httpd_sys_content_t /home/websites
After executing this, apache could read my files.
Important links I found in troubleshooting:
http://fedora.redhat.com/docs/selinux-apache-fc3
http://fedora.redhat.com/docs/selinux-faq-fc3/
http://lwn.net/Articles/105409/
I like where this SELinux thing is going. Permissions done right, for sure. This doesn't come with out growing pains though. It's complex (or so it seems to me after only working with it for a couple days) and will take some time to learn. I'm prepared for
some frustration....
Now many of you are probably asking yourself why would anyone (let alone me) want to bother with this? Well I think a simple example of one
4000
of the cool things is that even though something like /etc/passwd has DAC octal perms of 644 (rw-r--r--), apache still
can't read it because that file is not with in apache's security context. So any users on your system can't write a little script that reads your /etc/passwd file and basically posts it on a web page for the world to see (giving potential crackers a list of
valid user accounts on the system).
UPDATE: Thanks for the updated link Bob.
相关文章推荐
- SELinux导致Apache 403错误解决方法
- Apache-Shiro+Zookeeper系统集群安全解决方案之会话管理
- RedHat5.5 samba&selinux冲突解决方案
- apache 服务器时间 与 系统时间不一致的解决方案(限于windows)
- Apache 打开网页的时候等待时间过长的解决方案
- Apache-Shiro+Zookeeper系统集群安全解决方案之会话管理
- 关于Xutils框架出现无法访问HttpRequestBase 找不到org.apache.http.client.methods.HttpRequestBase解决方案
- Apache2服务启动失败 “本地计算机上的Apache服务启动后又停止了”的错误的解决方案
- Apache ProxyPass 出现503 Service Temporarily Unavailable 的解决方案
- eclipse加载maven工程提示pom.xml无法解析org.apache.maven.plugins:maven-resources-plugin:2.4.3解决方案
- Maven打包时报Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.2:war解决方案
- APACHE服务器出现No input file specified.的完美解决方案
- Apache跨平台解决方案
- CentOS6.5 服务器+apache5.3绑定多个域名+SELinux设置
- Apache下禁止php文件被直接访问的解决方案
- apache的SSL端口被占用的解决方案
- apache2.4报 (OS 64)指定的网络名不再可用 ,解决方案
- 在Windows2000平台下整合JDK1.4.1 + Apache2.0.44 + Tomcat4.1.18完全解决方案
- 终极解决方案 at org.apache.jsp.index_jsp._jspInit(index_jsp.java:22) 报空指针
- 关于Apache默认编码错误,导致网站乱码的解决方案