为什么需要 chmod o+r 父目录来修复 Nginx 和 Passenger 的 403 访问禁止错误?

为什么需要 chmod o+r 父目录来修复 Nginx 和 Passenger 的 403 访问禁止错误?

这可能是 Nginx 的问题,也可能是因为我不太了解 Unix 权限。

我们正在使用 Hudson CI 来部署我们的暂存实例。也是RAILS_ROOT如此/var/lib/hudson/jobs/JOBNAME/workspace

  • Hudson 以hudson用户身份运行
  • www-dataNginx 以用户身份运行
  • hudson并且nginx都是该www团体的成员
  • root我的 nginx conf 指向RAILS_ROOT/public与正常情况一致。
  • RAILS_ROOT/config/environment.rb归所有www-data(因此 Passenger 以 身份运行www-data
  • RAILS_ROOT其中的所有内容均归该www组所有,并且该组具有 r/w/x 权限

事实上,Nginx403 permission denied在请求任何 url 时都会抛出错误。error.log其中包含如下条目:public/index.html" is forbidden (13: Permission denied)

这些并没有修复或改变错误(每个都带有 Ngnix 的停止/启动):

  • chmod 777 -R RAILS_ROOT
  • chgrp www -R /var/lib/hudson

我也尝试使用 Nginx root,但乘客抱怨说找不到config/environment(尽管错误页面上显示的路径是正确的)。

修复方法是确保everybody对层次结构中的每个目录都有读取权限。 在这种情况下chmod o+r /var/lib/hudson

但如果团体对该目录具有读取权限,并且 nginx 是该目录所有者组的成员,为什么需要允许每个人读权限?关于权限,还有什么你不明白的吗?

$nginx -V
nginx version: nginx/0.7.61
built by gcc 4.4.1 (Ubuntu 4.4.1-4ubuntu8) 
configure arguments: --prefix=/opt/nginx --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/ext/nginx --with-http_ssl_module --with-pcre=~/src/pcre-8.00/ --with-http_stub_status_module

$cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

答案1

www-data 可能有类似 的 shell /bin/false,因此如果您想检查问题究竟出在哪里,请执行以下操作:切换到 root(susudo -i),然后运行

# su -s /bin/bash www-data
$ cat /path/to/problem/file

您将会看到,这个问题是关于权限的问题还是其他地方的问题。

更新型多巴胺
嗯...我没有查看帖子写作时间。serverfault.com 上有“necropost”成就吗?:)

答案2

*nix 和组权限可能有点奇怪。如果用户是多个组的成员,他们可能有权访问某些文件,但实际上却无法访问它们!据我所知,在典型的 *nix 系统上,您实际上一次似乎属于一个组。成为成员意味着您可以切换到另一个组,或者更彻底检查事物的程序(如在 redhat 变体上运行的 su)也将能够看到您是正确的组的成员。

有一个 sg 命令可以让你切换组,就像 su 切换用户一样。

为了解决您的实际问题,我认为您可以更改 passwd 文件中的组,以便您想要的组是默认组。假设它不会导致您无法访问所需的其他文件。

我相信还有其他适用于 *nix 的 ACL 解决方案可以安装,它们以更直观的方式工作,但我真的对它们并不了解。

答案3

不,这是乘客的问题。我正在使用 unicorn 运行 rails 应用程序,并授予 nginx 最低权限。(整个应用程序目录不是全局/组可读/可执行的 - 除了根目录 710 和公共目录 710 及其内部文件 640)

相关内容