(13)权限被拒绝:访问/~我拒绝。

时间:2022-01-11 16:54:55

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).

我正在尝试配置Apache httpd。conf(在我的CentOS 6.4上)允许访问我的用户目录(即~me/public_html/index.html)。

I changed the original httpd.conf (i.e. out-of-the-box) as follows:

我改变了原来的httpd。conf(即开箱即用)如下:

[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:

这在原则上应该提供访问http://myhost/~me,但是我得到了可怕的错误:

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:

我检查了文件/var/log/httpd/error_log,当然,它是这样写的:

(13)Permission denied: access to /~me denied

The first weird thing I noticed is that a / is prepended to ~me.

我注意到的第一个奇怪的事情是,a /被预先处罚了。

  • Where does that leading / come from?
  • 这是从哪里来的?
  • Is it only a "red herring"?
  • 它只是一个“红鲱鱼”吗?
  • Or is this pointing to the root cause of the problem (i.e. something else I need to modify in httpd.conf)?
  • 或者是指向问题的根本原因(例如,我需要在httpd.conf中修改其他东西)?

Most importantly, since I know that my ~me/public_html is has world-readable permissions, how do I troubleshoot a problem like this?

最重要的是,因为我知道我的~me/public_html具有世界可读的权限,我如何排除这样的问题?

Is there a way to find out why "access to /~me denied"?

有没有办法找出为什么“访问/~我拒绝”?

  • SELinux?
  • SELinux吗?
  • httpd.conf?
  • httpd . conf吗?
  • directory permissions?
  • 目录的权限吗?
  • all of the above?
  • 以上所有的?

Update 1, answering the 2 questions in the comments by @UlrichSchwarz below:

更新1,在@UlrichSchwarz的评论中回答2个问题:

  1. The home directory does seem to have the 'x' permission:

    主目录似乎有“x”权限:

    [root@myhost ~]# ls -lad /home/me

    [root@myhost ~]# ls -lad /home/me。

    drwxr-xr-x. 33 me me 4096 Feb 8 16:30 /home/me

    drwxr-xr-x。2月8日下午4点30分。

  2. SELinux info on public_html:

    在public_html SELinux信息:

    [root@myhost ~]# ls -Z -d /home/me/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/

    drwxrwxr-x。我我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):

更新2,在我验证了这确实是一个SELinux问题(感谢@Scolytus的提示):

  1. I ran the command:

    我跑的命令:

    chcon -R -t httpd_user_content_t /home/me/public_html/

    chcon -R -t httpd_user_content_t /home/me/public_html/。

    Still no go.

    还没有走。

    [root@myhost ~]# ls -Z -d /home/me/public_html/

    [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/

    drwxrwxr-x。我我unconfined_u:object_r:httpd_user_content_t:s0 /home/me/public_html /

  2. Then I ran "Allow HTTPD to read home directories" from the command line:

    然后我从命令行运行“允许HTTPD读取主目录”:

    setsebool -P httpd_enable_homedirs=1

    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:

/var/log/httpd/error_log现在显示(除了(13)权限拒绝错误):

 [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?

也许问题在于context_system_u和httpd_user_content_t之间的差异?

What else do I need to do? (without disabling SELinux completely, that is)

我还需要做什么?(如果不完全禁用SELinux,那就是)


Update 3, thanks to information in @lserni's answer, I discovered the ausearch command:

更新3,感谢@lserni的回复,我发现了ausearch命令:

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?

嗯?为什么/home/me,而不是/home/me/public_html?

Here is the output of ls -Zd /home/me/:

这里是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?

我是否应该在/home/me上运行chcon -t httpd_user_content_t ?

Continuing to research...

继续研究…


Update 4: Success!

4:更新成功!

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/

2 个解决方案

#1


5  

I've seen a slightly different version of the command you gave, supplied by sealert:

我看到了一个稍微不同版本的命令,由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.

SELinux拒绝使用httpd请求访问/var/www/html/file1。/var/www/html/file1有一个用于不同程序共享的上下文。如果您想要从httpd*享/ var/w/www/html/file1,那么您需要将它的文件上下文更改为public_content_t。如果您不打算访问此访问,这可能是入侵尝试的信号。

Allowing Access:

允许访问:

You can alter the file context by executing chcon -t public_content_t '/var/www/html/file1'

可以通过执行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.

大多数与selinux相关的信息通常都在auditd日志中,但是您可能需要一些工具,比如sealert来为您解码。我做了一个简短的搜索,找到了这个我不知道的工具,但是看起来很有趣:SELinux GUI。

Addendum: Some examples with semanage

附录:一些带有语义的例子。

#2


2  

I can't check immediately, but I recall that commenting out the UserDir disabled isn't the same as enabling!

我不能立即检查,但是我记得注释掉UserDir禁用不等于启用!

More specifically, I think you need to include a line in your https.conf file

更具体地说,我认为您需要在https中包含一行。配置文件

Userdir enabled me

#1


5  

I've seen a slightly different version of the command you gave, supplied by sealert:

我看到了一个稍微不同版本的命令,由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.

SELinux拒绝使用httpd请求访问/var/www/html/file1。/var/www/html/file1有一个用于不同程序共享的上下文。如果您想要从httpd*享/ var/w/www/html/file1,那么您需要将它的文件上下文更改为public_content_t。如果您不打算访问此访问,这可能是入侵尝试的信号。

Allowing Access:

允许访问:

You can alter the file context by executing chcon -t public_content_t '/var/www/html/file1'

可以通过执行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.

大多数与selinux相关的信息通常都在auditd日志中,但是您可能需要一些工具,比如sealert来为您解码。我做了一个简短的搜索,找到了这个我不知道的工具,但是看起来很有趣:SELinux GUI。

Addendum: Some examples with semanage

附录:一些带有语义的例子。

#2


2  

I can't check immediately, but I recall that commenting out the UserDir disabled isn't the same as enabling!

我不能立即检查,但是我记得注释掉UserDir禁用不等于启用!

More specifically, I think you need to include a line in your https.conf file

更具体地说,我认为您需要在https中包含一行。配置文件

Userdir enabled me