更新摘要
/var/www 目录归其所有,root:root
这意味着没有人可以使用它,而且它完全没用。由于我们都想要一个实际工作的 Web 服务器(并且没有人应该以“root”身份登录),所以我们需要解决这个问题。
只有两个实体需要访问。
PHP/Perl/Ruby/Python都需要访问文件夹和文件,因为它们创建了许多文件夹和文件(即
/uploads/
)。这些脚本语言应该在 nginx 或 apache 下运行(或者甚至是一些其他的东西,比如 PHP 的 FastCGI)。开发商
他们如何获得访问权?我知道以前有人在某个地方做过这件事。然而,有数十亿个网站,您会认为会有更多关于这个主题的信息。
我知道 777 是所有者/组/其他的完全读/写/执行权限。因此,这似乎不需要正确,因为它为随机用户提供了完全权限。
需要使用哪些权限,/var/www
以便:
- 源代码控制,如 git 或 svn
- 像“网站”这样的组中的用户(甚至添加到“www-data”)
- 像 apache 或 lighthttpd 这样的服务器
- 和 PHP/Perl/Ruby
都可以在那里读取、创建和运行文件(和目录)吗?
如果我是正确的,Ruby 和 PHP 脚本不会直接“执行”——而是传递给解释器。所以不需要对/var/www
...中的文件执行权限?因此,似乎正确的许可chmod -R 1660
是
- 这四个实体可共享的所有文件
- 所有文件都错误地不可执行
- 完全阻止目录中的其他所有人
- 将所有未来文件的权限模式设置为“粘性”
这个对吗?
更新 1:我刚刚意识到文件和目录可能需要不同的权限 - 我在谈论上面的文件,所以我不确定目录权限需要是什么。
更新 2:文件夹结构发生了/var/www
巨大变化,因为上述四个实体之一总是添加(有时删除)文件夹和子文件夹很多层级。他们还创建和删除其他 3 个实体可能需要读/写访问权限的文件。因此,权限需要对文件和目录都做上面的四件事。由于它们都不应该需要执行权限(请参阅上面有关 ruby/php 的问题),我认为rw-rw-r--
权限将是所需要的并且完全安全,因为这四个实体由受信任的人员(请参阅#2)和所有其他用户运行系统只有读取权限。
更新 3:这适用于个人开发机器和私人公司服务器。没有像共享主机这样的随机“网络客户”。
更新 4: slicehost 的 这篇文章似乎最能解释为 www 文件夹设置权限所需的内容。但是,我不确定使用 PHP 或 svn/git 运行的用户或组 apache/nginx 以及如何更改它们。
更新 5:我(我认为)终于找到了一种让这一切正常工作的方法(答案如下)。但是,我不知道这是否是正确且安全的方法。因此,我开始了赏金。拥有保护和管理 www 目录的最佳方法的人获胜。
经过更多的研究,似乎另一种(可能更好的方法)来回答这个问题,就是像这样设置 www 文件夹。
sudo usermod -a -G developer user1
(将每个用户添加到开发者组)sudo chgrp -R developer /var/www/site.com/
以便开发人员可以在那里工作sudo chmod -R 2774 /var/www/site.com/
这样只有开发人员可以创建/编辑文件(其他/世界可以读取)sudo chgrp -R www-data /var/www/site.com/uploads
以便 www-data (apache/nginx) 可以创建上传。由于
git
以任何用户调用它的身份运行,因此只要用户在“开发者”组中,他们就应该能够创建文件夹、编辑 PHP 文件和管理 git 存储库。注意:在步骤(3)中:2774中的“2”表示为目录“设置组ID”。这会导致在其中创建的新文件和子目录继承父目录的组 ID(而不是用户的主要组)参考:http ://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
我不确定它是否“正确”,但这是我在服务器上所做的:
请记住,您应该在目录上启用执行位,以便您可以列出内容。
在进行更多研究之后,似乎 git/svn TOOLS不是问题,因为它们以任何用户使用它们的身份运行。(但是,git/svn 守护进程是另一回事!)我用 git 创建/克隆的所有东西都有我的权限,并且列出了
/usr/bin
适合本文的 git 工具。Git权限解决了。
用户权限似乎可以通过将所有需要访问 www 目录的用户添加到
www-data
运行 apache(和 nginx)的组中来解决。所以这个问题的一个答案似乎是这样的:
默认情况下
/var/www
归所有root:root
,没有人可以在那里添加或更改文件。1)更改组所有者
首先,我们需要将 www 目录组更改为“www-data”而不是“root”组拥有
2) 将用户添加到 www-data
然后我们需要将当前用户(和其他任何人)添加到 www-data 组
3) CHMOD www 目录
更改权限,以便只有所有者(root)和组“www-data”中的所有用户可以 rwx(读/写/执行)文件和目录(其他人甚至都不能访问它)。
现在,任何具有访问权限的用户(即在“www-data”组中)创建的所有文件和目录都可以被 apache 和 php 读取/写入。
这个对吗?PHP/Ruby 创建的文件怎么样 - www-data 用户可以访问它们吗?
粘性不是权限继承。目录的粘性意味着只有文件的所有者或目录所有者才能重命名或删除目录中的该文件,尽管权限另有说明。因此 /tmp/ 上的 1777。
在经典的 Unix 中,没有基于文件系统的权限继承,只有当前进程的 umask。在 *BSD 或目录上设置了 setgid 的 Linux 上,新建文件的组字段将设置为与父目录的组字段相同。除此之外,您需要查看 ACL,在目录上使用“默认”ACL,它确实让您拥有继承的权限。
您应该首先定义: * 哪些用户可以访问系统 * 您的威胁模型是什么
例如,如果您正在与多个客户进行网络托管,并且您不希望他们看到彼此的文件,那么您可以为所有这些用户使用一个公共组“webcusts”,目录模式为 0705。然后文件由网络服务器进程(不在“webcusts”中)将看到其他权限并被允许;客户不能看到彼此的文件,用户可以弄乱自己的文件。但是,这确实意味着在您允许 CGI 或 PHP 的那一刻,您必须确保进程以特定用户身份运行(无论如何,对于一台主机上的多用户来说,这是一种很好的做法,为了问责制)。否则,客户可能会通过 CGI 来弄乱彼此的文件。
但是,如果网站的运行时用户与网站所有者相同,那么在脚本中存在安全漏洞的情况下,您确实会遇到无法保护内容免受滥用者侵害的问题。这就是专用主机获胜的地方,这样您就可以拥有一个不同于静态内容所有者的运行时用户,而不必太担心与其他用户的交互。
我确实相信最好的方法是使用 Posix ACL。它们使用起来很舒服,并提供您需要的所有功能。
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
文件的所有者应该是创建它的人,而组应该是 www-data。目录/文件的模式通常是 755/644。而对于目录和文件,组需要写访问权限,mod 是 775/664。假设 paddy 是开发者。总而言之,这使得:
添加到@Xeoncross 的答案中,我认为最好分别配置文件和目录的权限。
这将允许开发人员在 /var/www 中创建和修改目录。这似乎很重要,因为开发人员可能需要创建其他目录或删除不再需要的目录。
它还将允许开发人员创建和修改代码文件(读取 HTML、PHP 文件等)。但是,仍然只允许其他所有人进行只读访问。