I am trying to configure Apache httpd.conf (on my CentOS 6.4) to allow access to my user directory (i.e. ~me/public_html/index.html).
I changed the original httpd.conf
(i.e. out-of-the-box) as follows:
[root@myhost www]# diff /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.orig.out-of-the-box
366c366
< #UserDir disabled
---
> UserDir disabled
373c373
< UserDir public_html
---
> #UserDir public_html
This should in principle provide access to http://myhost/~me
but instead, I am getting the dreaded error:
You don't have permission to access /~me on this server.
I checked the file /var/log/httpd/error_log and, sure enough, it reads:
(13)Permission denied: access to /~me denied
The first weird thing I noticed is that a /
is prepended to ~me
.
/
come from? Most importantly, since I know that my ~me/public_html
is has world-readable permissions, how do I troubleshoot a problem like this?
Is there a way to find out why "access to /~me denied"?
Update 1, answering the 2 questions in the comments by @UlrichSchwarz below:
The home directory does seem to have the 'x' permission:
[root@myhost ~]# ls -lad /home/me
drwxr-xr-x. 33 me me 4096 Feb 8 16:30 /home/me
SELinux info on public_html:
[root@myhost ~]# ls -Z -d /home/me/public_html/
drwxrwxr-x. me me unconfined_u:object_r:file_t:s0 /home/me/public_html/
Update 2, after I verified that this is indeed an SELinux issue (thanks to the tip by @Scolytus):
I ran the command:
chcon -R -t httpd_user_content_t /home/me/public_html/
Still no go.
[root@myhost ~]# ls -Z -d /home/me/public_html/
drwxrwxr-x. me me unconfined_u:object_r:httpd_user_content_t:s0 /home/me/public_html/
Then I ran "Allow HTTPD to read home directories" from the command line:
setsebool -P httpd_enable_homedirs=1
Still no go.
/var/log/httpd/error_log now shows (in addition to the (13)permission denied error) the following:
[notice] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[notice] Digest: generating secret for digest authentication ...
[notice] Digest: done
[notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
Perhaps the problem lies in the discrepancy between context_system_u and httpd_user_content_t?
What else do I need to do? (without disabling SELinux completely, that is)
Update 3, thanks to information in @lserni's answer, I discovered the ausearch command:
ausearch -m avc --start today
Which provided the following output:
time->Fri Jul 4 09:16:44 2014
type=SYSCALL msg=audit(1404479804.256:1312): arch=40000003 syscall=196 success=no exit=-13 a0=12c2c80 a1=bfeb1d00 a2=a34ff4 a3=2008171 items=0 ppid=5880 pid=5886 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=193 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1404479804.256:1312): avc: denied { getattr } for pid=5886 comm="httpd" path="/home/me" dev=dm-3 ino=2 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir
Huh? Why /home/me
and not /home/me/public_html
?
Here is the output of ls -Zd /home/me/
:
drwxr-xr-x. me me system_u:object_r:file_t:s0 /home/me/
Should I run the chcon -t httpd_user_content_t
on /home/me, too?
Continuing to research...
Update 4: Success!
I ran the command:
chcon -t httpd_user_content_t /home/me/
And all is well now.
[root@myhost sa]# ls -Z -d /home/me/
drwxr-xr-x. me me system_u:object_r:httpd_user_content_t:s0 /home/me/
We can solve this error by Providing the right permissions to the file using chown or chmod commands and also ensuring Python is running in the elevated mode permission .
(13) Permission Denied. Error 13 indicates a filesystem permissions problem. That is, Apache was denied access to a file or directory due to incorrect permissions. It does not, in general, imply a problem in the Apache configuration files.
Right-click the file or folder, and then click Properties. Click the Security tab. Under Group or user names, click your name to see the permissions that you have. Click Edit, click your name, select the check boxes for the permissions that you must have, and then click OK.
I've seen a slightly different version of the command you gave, supplied by sealert
:
SELinux denied access to /var/www/html/file1 requested by httpd. /var/www/html/file1 has a context used for sharing by different program. If you would like to share /var/www/html/file1 from httpd also, you need to change its file context to
public_content_t
. If you did not intend to this access, this could signal a intrusion attempt.Allowing Access:
You can alter the file context by executing chcon -t public_content_t '/var/www/html/file1'
Fix Command:
chcon -t public_content_t '/var/www/html/file1'
how do I troubleshoot a problem like this?
Most SELinux-related information is generally in the auditd logs, but you probably want some tool such as sealert
to decode it for you. I've done a brief search and came up with this tool that I didn't know of, but seems interesting: SELinux GUI.
Addendum: Some examples with semanage
I can't check immediately, but I recall that commenting out the UserDir disabled
isn't the same as enabling!
More specifically, I think you need to include a line in your https.conf file
Userdir enabled me
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With