Bug 453947
Summary: | SELinux prevents Apache from reading files in /var/www/html/ | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christopher Beland <beland> |
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 9 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-07-03 15:29:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Chris is you moved a file to this directory and it was owned by root and had 600 permissions on it, would you expect it to just work? With a mandadtory access system you need to not only make sure that files have the correct ownership, file permissions and Labels associated with them. SELinux does not and cannot rely on path, so labels on the inode is required. What is the security purpose in denying Apache access to these files? Why can't the system be made any smarter than it is now? If "restorecon" knows what labels these files *should* have, why is manual intervention necessary? Why aren't the labels set properly on the fly? Unix permissions are something I can fix in Nautilus. I can see the SELinux context there, but I can't do anything about it, and it's not obvious what *should* be done about it. I don't think users *should* have to learn how SELinux works in order to be able to use their computers; it adds too much complexity to an understanding that is already pretty complicated. Probably nothing. But these files are labeled as user_home_t, which is the label of most files in your home directory. If a compromized apache server is taken over you would probably not want it to access you home directory contents. Now you can argue that the mv/cp/install tools should handle this in a smarter fashion. But they work the same way for DAC. So upstream for coreutils wants MAC to follow the pattern. nautilus used to have the ability to change the context and I believe this is a bug in Fedora 9 that has been fixed in Rawhide. If you want to continue this discussion, please move it to email or a fedora list. |
I had a directory called /home/beland/www, which I wanted to publish. So, I moved it to /var/www/html/beland. When trying to load my homepage, I got the following error in the Apache log: (13)Permission denied: access to /beland/useful.html denied In order to fix this without using the command line, I had to change SELinux from "enforcing" to "permissive". The error message I got from setroubleshoot says: >> SELinux has denied httpd access to potentially mislabeled file(s) (./useful.html). This means that SELinux will not allow httpd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want httpd to access this files, you need to relabel them using restorecon -v './useful.html'. You might want to relabel the entire directory using restorecon -R -v '.'. << This is not very user friendly. The problem is being caused by an invisible attribute of the files (as far as most people are concerned) having to do with where they came from rather than where they are. It doesn't make sense that the security system would prevent Apache from accessing files *in the directory specifically dedicated to storing files Apache is supposed to access*. This over-protectiveness makes people more likely to disable the security system, leading to increased risk of break-in. This is with: selinux-policy-targeted-3.3.1-72.fc9.noarch httpd-2.2.8-3.x86_64